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 万条文档，5 秒
> 瓶颈：0x...
> 实际结果：2 秒（3.75x）
> 代码量：Python 的 4 倍
> 后来给数据库加了索引
> Python 版本，3 秒
> 比 Rust 版本还快 🤡
> 瓶颈根本不在 Python，在数据层 I/O
> 在优化之前，先 profile
2025.06 — 写了 3 篇后停更
计划写 8 篇，实际写了：
✓ 第 1 篇：服务注册与发现（Consul）
✓ 第 2 篇：API 网关，Nginx
✓ 第 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."
这个页面会持续更新，每次失败都值得记录。
如果你也有类似的经历，或 写信告诉我。