主线和附录的区别
主线和附录的分工，不是重要和不重要，而是两种性质不同的材料：主线是一条论述链，靠前后章节互相供给前提；附录是一组对照表和专题，默认读者已经走过主线，需要的是横向视角。
主线为什么按论述链组织
主线各章之间存在真实的依赖：问题模型给出成本判断，网络接入和同步与战斗给出主链路约束，执行模型和服务拆分承接这些约束，数据、版本、运营再向外扩展。抽掉中间环节，后面的结论就只剩下结论本身，换个项目就判错。所以主线的章节顺序是论证顺序，不完全等于开发流程顺序，按工程排期去重排阅读顺序，往往会破坏这条链。
附录为什么单独放在主线之外
附录内容有两个共同特点。一是横向对照性质：同一类话题按类型、按问题域、按工具散布在多章，压缩成对照反而更省事。二是更依赖具体形态：配置表管线、压测步骤、引擎清单这类内容随工具和阶段变化得快，放进主线会让论述链背上频繁修订的负担。让附录承担具体形态，让主线守住抽象判断，各得其所。
一条容易记的判断
不确定某篇内容属于哪边时，常见做法是问一句：去掉它，主线的论证链断不断。断，说明它承担了论述职责，属于主线；不断，说明它是横向补充，属于附录。这条判断也适合拿去整理自己团队的内部文档。
主线和附录的读者假设不同
主线假设读者在建立判断，愿意接受前后文依赖；附录假设读者已经带着问题，需要的是定位和核对。这个假设差异决定了两边的写法：主线展开推理和代价，附录压缩成对照和清单。用读附录的方式读主线，会漏掉推理；用读主线的方式读附录，又只会觉得太啰嗦。
附录的几组内容分别服务什么
- 游戏类型专题：给品类直觉，回答这类产品通常把复杂度压在哪里。
- 按问题域归纳：横向对照，把多章内容压成一张可以核对的表。
- 配置管线：协作流程，回答配置从编辑到生效的整条链路怎么治理。
- 容量扩缩：上线准备和长线治理的操作面，压测、规划和扩缩容。
- 引擎语言工具：选型背景材料，把工具生态放回商业和团队约束里。
以配置和容量为例看两边分工
- 配置这件事，主线在脚本与热更新一章讨论配置驱动与脚本驱动的边界，回答“什么变化不该走完整发布”；附录的配置管线一组，讨论表格怎么流转、怎么校验、怎么协作，回答“配置怎么安全地到达线上”。
- 容量这件事，主线在可观测性与稳定性一章讨论怎么判断系统接近极限、抖动从哪里来；附录的容量扩缩一组，讨论压测、容量规划和扩缩容的具体组织。
类似的关系也出现在问题模型与游戏类型专题之间：前者给出抽象维度，后者按品类回看这些维度分别被压在哪里。
一篇内容为什么放这边而不是那边
判断标准通常是看它回答判断问题还是操作问题。配置驱动该承载什么变化，这是判断问题，放主线；表格怎么校验、怎么流转，这是操作问题，放附录。系统接近极限怎么判断，放主线；压测怎么组织，放附录。这个标准也适合读者拿去整理自己团队的内部文档。
什么时候该离开主线去附录
三种时刻最值得：方案评审需要横向对照时，拿附录核对常见落点；盘点老项目时，拿附录当清单逐项过；给特定品类补直觉时，看类型专题讲同类产品把成本压在哪。离开主线是为了核对，不是为了代替判断。
附录不能替代的部分
附录给出的是常见落点，不是判断过程。同样一句“这类产品成本在数值与经济”，知道为什么的人能判断自己的项目属不属于这类，不知道的人只能照抄结论。这也是附录反复被要求“先读主线”的原因：没有主线，对照表就只是一张表。
再看问题模型和类型专题的分工
问题模型给的是抽象维度：状态共享范围、时间推进方式、资产复杂度、运营强度。类型专题按品类回看：同一类产品，这几个维度分别被什么玩法压重。前者教判断方法，后者给参照样本。只读后者，遇到混合形态的项目就没了抓手；只读前者，和策划、发行的沟通又少一层共同语言。
主线读完之后附录怎么用
反过来也有一种常见情况：主线读完了，项目进入上线准备和长线运营阶段，压测、迁移、配置协作这些操作面问题开始出现。这时附录的价值才真正兑现，按需查阅即可，不必在第一次阅读时全部消化。引擎语言工具一组同理，它是选型时的背景材料，不是排行榜。
两边的内容更新节奏也不同
主线讨论的是长期成立的判断，更新慢；附录里的工具、品类和流程形态更新快。这也影响引用方式：写内部方案时，引用主线的判断通常比引用附录的具体形态更耐久，附录更适合作为当下操作的核对材料。
顺读主线时遇到类似附录性质的内容，不必当场展开，标记下来留到对应阶段再查，通常比在论述中途跳出去更省力。
拿一个真实问题走一遍分工
假设问题是“活动配置发出去后，部分玩家拿到旧数值”。主线入口在脚本与热更新一章的配置驱动边界，以及版本发布一章的兼容窗口，回答为什么会出现版本组合失配；附录入口在配置管线一组的校验与下发流程，回答这次下发在哪一环漏了校验。主线给判断框架，附录给检查环节，两边一起用，问题才算被完整覆盖。
常见误区
- 把附录当捷径，直接拿对照表下结论，跳过主线的判断链。
- 把主线的抽象结论直接当操作手册用，忽略附录里的具体形态差异。
- 认为附录是低优先级内容完全不看，配置或工具部分长期靠传闻决策。
- 第一次阅读就主线附录混着读，两边互相干扰，都没读透。