笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
98% 并不算多：技术工程中“广泛支持”的陷阱
一句话概括：看似极高的 98% 覆盖率，在工程可靠性中可能意味着灾难性的失败率。
为什么 98% 听起来很棒，但实际很糟糕？
我们习惯性地认为 98% 是一个很高的比例。如果一个人买彩票中奖率高达 98%，那简直是天选之人；如果学生 98% 的考试都拿到满分，绝对能拿荣誉学位。但当我们把 98% 放到基本期望的语境中，情况就完全变了：
- 一家餐厅 98% 的情况下不会让顾客食物中毒，这意味着每个月（甚至每周）都会有人吃坏肚子。
- 一个雇主 98% 的时间按时发工资，你绝对不想在那里工作。
- 如果你吃饭后 98% 的情况会付钱，那剩下的 2% 会让你惹上大麻烦。
关键区别在于：98% 对“锦上添花”是好数字，但对“雪中送炭”是危险信号。比如，让婴儿在保姆照顾下 98% 存活率——这完全不可接受。
网页开发中的 98% 陷阱
文章作者 Hugo 以网站开发为例，揭露了一个常被忽视的真相：
如果一个网站使用时髦的新浏览器特性，并声称“对 98% 的人口有效”，那意味着它无法服务约 1.5 亿人（按全球 80 亿人口估算）。
更致命的是，98% 的“一般人口”覆盖率 ≠ 98% 的“你的受众”覆盖率。作者举了一个亲身经历：
几个月前，有人争论 CSS 嵌套（Nesting）特性。有人说它自 2023 年已成为标准，可以安全用于生产环境。但作者检查了某个客户的网站实际浏览器分布后，发现过去一年中，只有 ~70% 的访客浏览器支持这个新特性。即便在“一般受众”中支持率很高，但对该网站而言，30% 的访客被排除在外。
想象一下：你认识 100 个人，其中 2 个人正对着一块坏掉的屏幕。98% 的统计数字是一个偷懒的捷径。
真正的工程思维：优雅降级与边界情况
作者的核心观点是：
真正稳健的工程不在于“对大多数有效”，而在于优雅地处理边界情况。如果一个花哨的新特性无法优雅降级（graceful degradation），那么 98% 就不是“广泛支持”——它已经对 2% 的人连基本最低要求都没满足。
在技术选型中，我们常常被“市场占有率”、“浏览器兼容性表”上的高百分比所迷惑。但实际工程中，必须考虑：
- 你的受众的真实浏览器分布（通过分析日志获得，而非全局统计）。
- 功能失败的影响范围：如果是非核心功能（如动画效果），98% 可以接受；如果是支付流程、表单提交，98% 就是灾难。
- 降级策略：能否在不支持的环境下提供回退方案（如 CSS 的
@supports查询、JS 的特性检测）。
延伸思考：从 98% 到 99.999% 的鸿沟
这个观点可以延伸到更广的工程领域：
- 系统可靠性：99.9% 的可用性意味着每年宕机 8.76 小时，而 99.999% 只有 5.26 分钟。对于金融交易系统、医疗设备、自动驾驶，后者才是底线。
- 数据一致性：数据库 98% 的事务成功？那剩下的 2% 可能是数据损坏或丢失。
- 网络安全：98% 的防病毒率意味着每 50 个威胁就有 1 个漏网，这对勒索软件来说足够了。
结论
下次当你听到“这个特性 98% 的浏览器都支持”时，请反问自己：
- 那 2% 是谁？是我的用户吗？
- 如果失败了，后果有多严重？
- 有没有降级方案？
98% 不是“几乎全部”，而是“每 50 人中就有 1 人失败”。 在工程中，我们不是为平均数设计，而是为每一个具体的人设计。
原文链接：https://whynothugo.nl/journal/2026/07/03/98-isnt-very-much/