Museum of Failed Experiments
作品集展示成功。这里展示失败。
真实的技术成长不是直线向上的。
2025.08 — 2025.10
起因：REST API 太碎了，一个页面要调三四个接口。GraphQL 一次查询搞定，听起来很美好。
经过：第一个月确实爽。第二个月 N+1 查询爆发——一个看似简单的查询背后是 47 次数据库调用。第三个月缓存变得极其复杂，REST 用 HTTP 缓存就行，GraphQL 需要 Apollo Cache，学习成本远超预期。
结局：项目规模不够大。GraphQL 的优势在大型多团队协作中才能体现，一个人维护前后端，REST + Swagger 足够了。
💡 技术选型的正确问题不是"哪个更好"，而是"在什么规模下哪个更好"。
2025.11 | duration: 2 weeks
> Python 处理 10 万条文档：45 秒
> 目标：10x 提速
> 实际结果：12 秒（3.75x）
> 代码量：Python 的 4 倍
> 后来给数据库加了个索引
> Python 版本：8 秒
> 比 Rust 版本还快 🤡
> 瓶颈根本不在 Python，在数据库 I/O
> 教训：优化之前，先 profile
2025.06 — 写了 3 篇后停更
计划写 8 篇。实际写了：
✅ 第 1 篇：服务注册与发现（Consul）
✅ 第 2 篇：API 网关（Kong）
✅ 第 3 篇：服务间通信（gRPC vs REST）
❌ 第 4 篇：分布式事务 — 写不下去了
写到 Saga 和 TCC 的区别时，发现自己讲不清楚。更关键的是：写到一半意识到，大部分读者不需要微服务。单体 + 好的代码组织能解决 90% 的问题。
那 3 篇还在线，但我在开头加了警告："在决定微服务之前，先确认你真的需要它。"
2026.01
单机测试完美。两个浏览器同时编辑，延迟 < 50ms。
部署后 3 个用户同时编辑就开始丢消息。Nginx 的 WebSocket 代理配置有问题，连接被静默断开。修好 Nginx 后，OT 算法在复杂场景下产生冲突，文档内容错乱。
最终方案：砍掉实时协作。改成"锁定编辑"——一个人编辑时其他人只读。Redis 分布式锁，代码量减少 80%。
💡 Google Docs 团队有几十个人专门做协作。一个人做不了。
2025.12
Jenkins 配置 3 天 → Dockerfile 2 天 → Ansible 1 天
总共 6 天，部署一个 3 页面的静态网站。
最终方案：GitHub Actions + 一个 shell 脚本。配置时间：2 小时。
💡 基础设施的复杂度应该和项目规模成正比。
2024 — 2026
以前觉得覆盖率是代码质量的硬指标。低于 80% 就是不负责任。
现在觉得：覆盖率是过程指标，不是结果指标。100% 覆盖率的代码照样有 bug——你只是覆盖了"代码路径"，没有覆盖"业务场景"。
对于个人项目，我甚至不写单元测试了。写 E2E 测试，覆盖核心用户流程。性价比更高。
💬 你也有类似的经历？写一张便签贴上来
便签保存在浏览器本地，刷新不丢。
"The only real mistake is the one from which we learn nothing."
这个页面会持续更新。每次失败都值得被记录。
如果你也有类似的经历，欢迎 写信告诉我。