“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
硬编码功能开关没什么不对：反对过度工程化的技术宣言
功能开关（Feature Flag）用硬编码实现完全没问题，简单、可靠、安全，多数团队根本不需要昂贵的开关管理平台。
引子
功能开关（Feature Flags / Toggles）是现代软件产品中控制新功能可见性的常见手段。每当我们要灰度发布、渐进式上线或做 A/B 测试时，都会想到用开关把代码包起来。
实现功能开关的方式有好几种，但市面上被讨论最多、被营销得最猛烈的，总是那套"功能开关管理平台"（Feature Flag Management Software），比如 LaunchDarkly、Unleash 这类 SaaS 或自托管服务。而最朴素的实现方式——直接硬编码（hardcode）开关，反而很少有人正经讨论。
营销造神：从"一个开关"到"几千个开关"
那些功能开关管理平台的营销话术强大到了一种近乎不正常的程度：你几乎会认为，如果你说"我们不需要这类平台"，就等于承认自己在技术上不行。
我们是如何一步步被说服的？
起初只是"我们需要几个功能开关"，后来变成了"我们得扩展到几千个开关"。再后来，营销话术继续加码：
- 你绝对需要在运行时动态改功能开关；
- 你必须做到不重新部署、不重启服务、不清缓存、不迁移数据库；
- 连代码审查和测试都可以省掉，因为业务已经在着火了，唯一能灭火的办法就是改首页按钮的颜色。
对此，作者毫不留情地讽刺道："这种系统唯一应该亮起的旗子（flag，双关：旗帜/标志位），是十六进制颜色码 #ff0000 那种红色——表示警报/危险。"这话的意思是：如果真到了业务着火只能靠线上切开关来救的程度，你该担心的不是按钮颜色，而是系统已经陷入了极度不健康的运维状态。
架构视角：不过是阔气的 if 语句
从软件架构的角度看，功能开关管理平台本质上就是"被美化了的 if 语句"——只不过这些 if 语句被单独挪到了另一个进程中管理，用另一套基础设施去承载。
这意味着什么呢？
- 你要为这套系统提供独立的部署、托管、监控；
- 你要承担与之相关的运维责任；
- 你的系统里多了一个外部依赖，增加了分布式系统的相互耦合。
在多数场景中，这种复杂度的增加根本换不回同等价值的收益。每一个额外的移动部件（moving part）都应该经过严格的审视：它是否真的必要？它引入的风险，是否值得它解决的问题？
开发周期视角：非确定性的噩梦
从软件开发生命周期（SDLC）来看，功能开关管理平台引入了非确定性行为（non-deterministic behaviour）。
什么意思？同样的代码、同样的版本，在不同时间点运行，行为可能完全不同——因为开关的状态是由外部系统控制的，随时可能被线上改动。这让开发者很难在本地复现问题，也让代码评审和测试变得困难。
长期存在的功能开关（long-lived feature flags）是众所周知的。即便最初出于好意——比如为了平滑上线——一旦开关活得太久，它就会变成技术债，让代码库逐渐"钙化"（ossify），即架构变得僵硬，难以重构。
当然，硬编码的开关也存在这个问题——如果一个硬编码开关几个月没被移除，同样会积累技术债。但关键在于：硬编码开关是看得见、摸得着的。它就在你的代码库里，review 的时候会看见，重构的时候会碰到，相比一个藏在远程配置中心里的开关，更容易被发现并清理。
安全视角：攻击面的扩张
从安全角度看，功能开关管理平台也是一个负债。
每新增一个外部系统，就意味着攻击面（attack surface）的扩张。现在，攻击者不仅可能攻击你的应用本身，还可能攻击你的开关管理系统；一旦开关被恶意篡改，攻击者可以直接影响你的应用行为——甚至在没有代码部署的情况下让某些隐藏功能暴露或关闭。
这种风险对大多数团队来说是不成比例的：你为了"运行时改配置方便"增加了安全风险，但你未必真的需要那种便利。
硬编码开关：最无聊的方式就是最好的方式
硬编码功能开关直接消除了上述这些问题。它简单、可靠、安全。
作者强调："这是最无聊的方式，但也正因如此，这是最好的方式。"
具体操作建议如下：
- 从 JSON 配置文件开始：写一个简单的 JSON 文件，在应用启动时读取它，用它来控制功能的可见性。
- 保持开关的目录清晰：定期检查你的开关列表，删掉那些不再需要的。
- 如果开关活得太久：那就把它变成代码里的默认行为——直接把那条分支删掉，让功能完全成为正式功能。这比留着永远不动的开关干净得多。
- 改动走正常开发流程：如果你要改某个开关的值，那就走常规的代码提交、Code Review、测试、部署流程。这本身就是一种天然的保障——比线上偷偷改配置稳妥多了。
对绝大多数团队和产品来说，这种硬编码方式完全够用，而且能跑很长一段时间。
什么时候才真正需要专业平台？
作者并非全盘否定功能开关管理平台，而是提出了一个清晰的分界：
当一个团队的规模真正到了需要在运行时大规模修改功能开关状态时——类似于前端 SPA 里状态管理工具（如 Redux）的演进逻辑——那时你自然会知道你需要它。
这是一种"经验驱动"的判断：你遇到了真实的瓶颈，再去引入相应的工具。而不是在没有任何问题时凭空引入一套复杂的系统，然后被它的复杂度反噬。
过早优化是万恶之源
作者引用了一个经典原则：过早优化是万恶之源（Premature optimization is the root of all evil）。
在团队规模很小、产品阶段很早期、功能改动频率不高的情况下，就兴师动众搭建一整套开关管理平台，属于典型的过度设计（over-engineering）。这不是好的设计，更不是好的工程。它的唯一作用，也许只是让某些人在技术会议上、当销售型的演讲者问到"有谁在使用功能开关管理平台吗"的时候，能够沾沾自喜地举手——那种短暂的自我满足感。
结语
功能开关是一个有用的工具，但和所有工具一样，关键在于是不是用对了地方。在绝大多数场景下，硬编码开关就是最合适的工具：它没有多余的依赖、没有额外的运维成本、没有非确定性的黑魔法、没有安全漏洞的暴露面。它朴素，但可靠。
如果你真的有一天需要更强大的开关能力，你会在那个时刻清楚地知道——因为你会被真实的业务需求和规模问题推动着去改变，而不是因为一篇营销博客让你觉得现在就该上。