技术栈
Stack 不是工具排行，而是一份决策框架：要运营这类业务，哪些层必须存在、每层什么时候变得不可回避、有哪些方案类型可以选。
怎么读一个 Stack
每一层都回答四个问题：为什么需要它、什么时候需要、能不能先不做、有哪些方案类型。我们不会在这里推荐任何厂商——工具只作为「下一步可以研究什么」出现，并且全部标注核实状态。
已完成梳理
这些 Stack 的每一层都已经写明问题、时机与方案类型。
规划中
层级结构已确定，但每层的方案取舍尚未完成系统梳理，因此暂不公布详细内容。
把 Stack 当待办清单用
Stack 里的每一层都可以落成三个动作：判断它现在是否不可回避、写下你能接受的方案类型、给它设一个触发条件。不要一次读完十二层再决定怎么动手，那会变成一场没有结论的选型会。更实际的做法是只挑当前真正卡住你的那一层，把方案类型写成一句话，然后回去写产品代码。
方案类型不等于具体厂商。「对象存储」「托管数据库」「事务邮件发送」说的是类型，「用哪一家」是下一步的事。先把类型定下来，你才知道要比较什么，也才看得懂各家官方页面在讲什么。这一步花的时间通常比你以为的少。
层与层之间会互相咬住的地方
- 域名的控制权是邮件配置的前提。SPF、DKIM、DMARC 都是 DNS 记录，改不了 DNS 就发不出可信的事务邮件。
- 鉴权与计费通常要一起设计。订阅状态挂在哪个用户标识上、升级降级怎么同步权限，分开做，后面补起来的代价更大。
- 数据存放位置会影响你能选哪些分析与监控工具。用户数据放在哪里，在选数据层时就要想清楚，上线后再迁移要动的是一整条链路。
- 部署区域决定延迟下限，也决定日志与备份放在哪里。区域定下来之后，更换的成本通常高于一开始就选对。
- 分析与监控至少要能回答两个问题：谁在用、哪里坏了。只装一个访问统计，回答不了付费用户遇到的那类问题。
什么时候需要回来重看
- 月成本开始随用量明显上升时。这通常说明某一层的方案类型需要更换，而不是提醒你去砍功能。
- 第一次有人真的付钱时。收款、发票与退款会在这一刻暴露所有没想清楚的环节。
- 某个官方页面改了规则，而你的业务正好依赖它时。先确认改动范围，再判断要不要动结构。
- 准备让第二个人参与时。你脑子里的约定会变成文档、权限和交接问题。
常见问题
我可以只做其中几层，跳过其它层吗？
可以，但要清楚跳过的代价。多数层可以推迟，少数不行——比如域名与收款通道，等到需要时再补，返工成本比一开始就留出位置更高。技术栈页面会标出每一层什么时候必须做、什么时候可以推迟。
照着 Stack 一层层买齐，是不是就能上线了？
不是。Stack 说明的是「要运营这类业务，哪些层必须存在」，不是采购清单，也不是推荐某个具体服务。每层里选什么，取决于你的成本结构、目标市场和你自己能接受的运维负担。
为什么有些层一直显示规划中？
因为那一层的方案取舍还没有完成系统梳理。我们宁可标注规划中，也不填充未经验证的内容——层级的骨架可以先公布，但没有核实过的细节不写。
不同 Stack 之间可以混用吗？
可以，而且很常见。Stack 是按业务类型划分的参考结构，不是互斥的技术选型。同一个项目里，支付层可能借用另一个 Stack 的选择，只要你自己清楚每一层的责任边界。