体例与中立性约定

用途：说明本站的组织方式、每页固定骨架，以及内容边界从哪里划起

组织方式

站点按三层组织：

领域（架构 / 基础 / 集成与中间件 / 企业软件语汇 / AI 工程化）
  └─ 技术（DDD、分布式事务、MySQL、Redis、RocketMQ、Elasticsearch、S2P、Agent 门禁 …）
       └─ 概念词条（每个概念独立成页）

一个概念一页，而不是一个大而全的长文档。理由是查阅场景：绝大多数时候要查的是“聚合到底怎么划”“MVCC 的可见性规则是什么”，而不是“把 MySQL 从头读一遍”。

技术页是该技术的词条目录，同时列出尚未成文的概念，避免用空页面充数。

两档深度与统一骨架

词条分两档，档位标注在页面自身，不含糊：

档	目标	必备小节	篇幅
核心词条	每个技术的主干概念，要求能直接指导设计与排障	定义或问题陈述、机制与规则、参数或阈值、可复算示例、排查清单、常见误区、延伸阅读	3000 字以上
支撑词条	速查型概念，给出判据与取舍	定义或问题陈述、要点表格、常见误区、延伸阅读	1200-2000 字

两档共用的骨架约定：开篇必须先说“这是什么、解决什么问题”；正文以可核对的判据（表格、参数、条件）为主；结尾固定给“常见误区”和“延伸阅读”。小节标题会按内容调整，但这四件事不缺。

判断某页属于哪一档：看它有没有“可复算示例”和“排查清单”。有即核心词条，没有即支撑词条。

中立性约定

这是本站的硬边界，写任何一页都遵守：

1. 例子取自公开的行业通用场景：电商下单、银行转账、机票改签、保险理赔、内容审核等，不使用任何特定企业的业务流程、字段命名或数据结构。
2. 不引用任何雇主、客户或内部系统：不出现内部系统名、库表名、接口名、组织与人员信息，也不描述“某次项目里我们怎么做”。
3. 开源参考只列项目名：用于说明“这个概念在真实项目里长什么样”，不构成推荐；同名项目可能有多个，以官方仓库为准。
4. 观点标注来源：属于某位作者或某本书的主张时写明作者，而不是当作无主常识陈述。
5. 区分事实与经验：机制性内容（如索引结构、内存模型）按公开规范陈述；取舍性内容（如聚合该划多大）明确标注为经验判断，并给出判据而不是结论。

不做什么

• 不是入门教程。 默认读者具备工程经验，不做从零铺垫。
• 不追求一次写满。 支撑词条会按使用反馈逐篇升级到核心档，升级标准见上表。
• 不含个人项目经历与面试话术。 需要表达“我做过什么”的场合是简历与面谈，不是这里。

勘误与演进

词条独立演进，页面底部显示最后更新时间。发现机制性错误（例如把隔离级别写错、把参数默认值写错）请直接指出，这类错误会优先修，因为它比缺内容更有害。