写完的东西是要维护的。维护的成本跟代码量基本成正比，所以最划算的优化是 不优化。
三个问题，写完之前先问
- 这个功能真的有人用吗？ 没想清楚给谁用的功能，写完也没人点。
- 能不能用已有的东西拼出来？ 一个 Markdown 文件加一个模板，往往比一套 CMS 更耐用。
- 出问题的时候我要怎么知道？ 没有日志和告警的功能，等于上线即失联。
依赖也是债
每加一个依赖，你就在别人的发布节奏上绑了一根线。升级、破坏性变更、 供应链问题，都得跟着处理。
我倾向的边界是：
- 能用标准库就不引第三方
- 引了就要能说清它解决了什么问题，以及删掉它会怎样
- 只在构建期用的工具，不要带进运行环境
这个站运行时只有 Flask、Flask-Login、bcrypt、Markdown 几个包，
pip list 一屏能看完。两年后回来看，还有很大概率能直接跑起来。
简单的判断标准
一个改动如果没法在十分钟内解释给不写代码的人，通常说明它太复杂了， 或者我还没想清楚。这时候应该停下来拆一拆，而不是继续往上堆。
留出口
数据结构比接口活得久。改接口容易，改表结构难。所以：
- 数据库字段宁可留空，不要塞语义不明的东西
- 配置项全部走环境变量，不写死在代码里
- 内容与展示分离：文案在数据里，模板只负责排版
做到这三条，换前端、换部署方式都是小事。