架构设计

## 任务目标

请把已确认的需求整理为开发能够逐项实现的架构交接稿。先沿用现有系统边界，说明确有必要新增或调整的部分。

交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

需求或架构问题：可留空；沿用当前已说明的功能目标和验收期望
工程或设计资料：可留空；从当前目录、现有接口、数据结构及已有需求材料获取

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 确认现有模块、入口、配置和数据流，标出已存在的复用能力。
- 从需求与调用方提取字段含义、状态、权限及失败处理约定，不让用户重新抄接口清单。

### 可采用的默认处理

- 保留当前系统边界和技术选型，以最小必要变化描述职责与调用关系。
- 无性能目标时先列测量条件，不承诺吞吐；没有真实目录时明确区分拟新增位置与已存在文件。

### 必须有依据的事项

- 影响数据归属、业务状态或外部契约的决策无法从材料确定时，集中列出对应决策及影响，不暂停无关设计。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 只有业务文字时交付标明假设的模块职责、接口草案和调用流程；代码路径标为建议。
- 缺少外部接口时先明确本系统边界、所需契约和不依赖该接口的实施顺序。

## 执行要求

按实施方案、文件职责、数据结构与接口、调用流程、待澄清事项组织交付。类图适合表达类和接口时再使用，不强迫所有语言或系统采用面向对象结构。

完成以下工作：
1. 将需求映射到现有入口和模块，区分已知约束、可自主决定的实现细节与影响架构的未知条件。没有真实目录或接口资料时，只给带假设的设计，不把猜测路径当作已存在文件；阻断条件集中说明原因和所需资料。
2. 给出实施方案及选择依据，优先复用已验证的框架、组件和部署方式。新增依赖要说明具体解决什么问题、版本约束及维护成本，不因“可扩展”就拆成多个服务，也不凭空承诺吞吐量或可用率。
3. 列出相对路径、文件职责、变更类型与所属模块，标明实际启动入口和配置读取入口。区分已存在路径与拟新增路径；避免同一责任散落多处，不能只列抽象层名称而缺少可落地文件。
4. 定义关键数据结构和接口：输入、输出、类型、必填、错误语义及调用方。涉及持久化时补上字段含义和约束；涉及身份或租户时说明校验位置、数据归属和调用上下文来源，不默认由前端传参即可可信。
5. 为主要成功路径和有业务影响的失败路径编写调用流程。流程中的模块、接口、参数和返回值必须能在前述清单找到对应定义；标出初始化、状态变化、事务边界和重试条件，不能把异常分支省略为“系统处理”。
6. 做交叉核对：每项验收条件由哪些文件和接口承接，流程引用是否悬空，错误状态是否可恢复。提供 Mermaid 时实际渲染后才能声明语法通过；没有渲染环境则标注未验证，并保留文字流程供开发核对。

## 交付与验收

输出顺序：实施方案；文件职责表；数据结构与接口表；主要调用流程；“验收条件→接口→文件”映射；待澄清事项。表中分别保留现状、拟议变更和验证方式，不混写成已完成事实。每个待澄清项说明它会影响哪个设计决定；若只影响局部实现，先完成其余交接内容。最终以接口名称一致、文件职责清楚、需求能追溯且没有未标记假设作为评审标准。

### 本条完成检查

- 需求、接口、数据、文件职责和调用流程名称一致。
- 现状、建议与待确认内容明确分开，开发者可据此安排可验证的工作项。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

整理说明：该组织方式参考下方公开实现，权限边界和可验证性要求为本模板补充。

官方来源：https://github.com/FoundationAgents/MetaGPT/blob/11cdf466d042aece04fc6cfd13b28e1a70341b1f/metagpt/actions/design_api_an.py

来源许可说明：MIT（https://github.com/FoundationAgents/MetaGPT/blob/11cdf466d042aece04fc6cfd13b28e1a70341b1f/LICENSE）。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。

## 任务目标

请为当前微信小程序制定或审查分包方案。

以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

分包规划目标：从现有 app.json 和可取得的构建体积报告检查主包压力与跨包引用；没有超限现象时先按真实启动和常用业务路径复核现有包归属。
工程或构建资料：读取小程序目录、app.json、TabBar、分享和扫码入口、公共资源引用、构建报告与主体及基础库配置。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 梳理启动页、TabBar 和直接进入页面，追踪脚本、组件及静态资源归属。
- 检查普通分包嵌套、跨包依赖及未被覆盖资源，识别独立分包和分包异步化是否真的需要。
- 从本次构建报告取得上传包体，结合可确认主体、发布渠道和当前官方规则核对限制。

### 可采用的默认处理

- 默认审查并提供规划，不迁移文件或发布；明确重构时才按受影响页面实施最小包调整。
- 优先保留入口和公共依赖，未证实收益不引入独立分包或异步跨包能力。
- 缺体积报告时只给待测项和资源候选，不以源码目录大小或旧平台限额宣称可发布。

### 必须有依据的事项

- 拟迁移页面承接外部分享或扫码，而入口兼容要求与初始化依赖无法确定，不能自行改变既有直达路径。
- 主体或发布渠道不明导致适用体积限制无法确认时，不给最终发布合规结论。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 只有目录和配置时交付页面归属、引用关系及最小调整草案，所有包体栏标待构建。
- 无法使用开发者工具时给构建取证与冷启动、分享直达、弱网首次下载的真机验收路径。

## 执行要求

按微信小程序的包结构和发布要求审查方案。普通分包、独立分包和分包异步化的能力边界不同；所有限制需结合本次发布时的官方说明核实。

1. 从真实入口梳理启动页、TabBar 页面、常用业务路径和低频功能，列明每个页面依赖的脚本、组件及静态资源。优先让首个业务任务所需内容清晰可控，不以平均分配文件大小作为分包目标。
2. 对照 app.json 的分包配置核查目录，保证 TabBar 页面留在主包、分包根目录没有互相嵌套。找出未被分包覆盖而意外进入主包的资源，说明它们是公共依赖还是可以迁移的业务资源。
3. 检查普通分包之间的脚本、模板和资源引用，明确允许依赖主包的部分。若需要使用分包异步化或独立分包，单独核查该能力的版本与入口要求，不能只修改路径后假定运行时一定能找到依赖。
4. 使用构建报告记录主包、各分包和全部包体积，区分源码目录大小与最终上传体积。按当前主体和发布渠道核对平台限制，给出超限资源的具体位置及压缩、按需加载或去重方案，不沿用网上过时数字。
5. 检查冷启动、页面分享直达、扫码进入、TabBar 切换和从主包进入分包的路径。分包首次下载失败时给出用户可理解的反馈和重试入口，避免页面空白后只能退出小程序。
6. 在开发者工具构建后进行真机验证，覆盖弱网、首次下载、再次进入和升级后的资源加载。对于抽出的公共模块，重点回归初始化顺序与业务状态，记录体积和启动体验的实际变化。

## 交付与验收

输出：页面与包归属表、依赖关系、配置改动、包体实测和进入路径验收表。没有构建结果时保留体积栏待测，不能把估算值作为可发布证明。涉及重构先列明受影响页面，保留已有业务入口和必要的兼容处理。

### 本条完成检查

- 交付主包和各分包的页面归属、公共依赖及配置建议，确认 TabBar 与跨包引用规则。
- 分别记录主包、分包、总包实际上传体积及采用的当前限制依据。
- 验证启动、直达、TabBar、分包下载失败和再次进入；未构建或未真机验证不宣称可发布。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

官方来源（2026-09-08 核验）：
- [腾讯微信《微信小程序：分包加载》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages.html)
- [腾讯微信《微信小程序：使用分包》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages/basic.html)

## 任务目标

请定位 Redis 热 Key 流量，并评审访问分散方案。

以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

热点业务：从当前问题或已有访问采样中选择集中访问的业务对象；没有热度证据时从调用代码识别热点候选，先建立观测窗口，不将大 Key 直接认定为热 Key。
工程与访问资料：读取 Key 生成与访问代码、缓存更新和回源链路、实例拓扑以及已有采样和监控记录，自动确认客户端、分片与可用观测能力。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 关联业务入口、Key 模式、读写调用和单 Key 所在分片。
- 读取同一时间窗口的访问频率、响应体大小、读写比例及集中来源。
- 追踪本地缓存、请求合并、TTL、更新失效和数据库回源策略。
- 核对实例类型与客户端能力，区分单 Key、单分片和全实例容量压力。

### 可采用的默认处理

- 默认只读定位与方案评审，不复制热点数据、改分片或启用读写分离。
- 没有实测时只列热点候选及有预算的采样方法，收益作为待验证假设。
- 一致性要求未知时保留现有读取路径，缓存副本和本地短缓存仅作为附条件候选。

### 必须有依据的事项

- 状态、库存、权限等读取是否允许陈旧及可容忍时间没有依据时，不选择牺牲一致性的分流方案。
- 热点缓存失效后的权威来源或业务失败行为不明时，不把无限回源或成功空结果当成降级。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 没有流量记录时交付热点证据采集表和单 Key、分片、实例压力的判别流程。
- 提供请求合并、限流、本地缓存与副本的条件对比，以及热点切换和更新失败的测试矩阵。

## 执行要求

适用范围：Redis或Tair的访问热点处理；Key大小与访问热度分别判断。控制台能力和读写分离方案须核对实际实例类型与业务一致性要求。

定位单个 Key 所在的具体分片；选择热点复制或读写分离时，评估相应的一致性代价。

检查步骤：
1. 以业务入口和时间窗口确认访问集中在什么对象，区分单Key高频、单分片集中与全实例容量不足；离线数据大小不能作为访问频率的证据。
2. 结合应用采样与已有实例指标识别真正热点，记录读写比例、响应体大小、请求集中来源及下游行为；采集本身要有资源预算，避免无限记录所有请求。
3. 区分可短暂陈旧的读取与必须保持最新的状态决策，说明缓存未命中或热点失效时的回源承载量；写热点不要用只读扩容冒充解决方案。
4. 比较请求合并、业务限流、本地短缓存、热点副本或业务拆分，分别列出适用前提、更新成本与失败行为；不默认采用所有方案，也不只计算理论吞吐。
5. 为候选方案定义缓存更新、版本识别、失效与恢复流程，说明多副本之间可能短暂不一致时用户会看到什么，以及如何避免旧值长期残留。
6. 用正常流量、突发热点、热点切换和更新失败验证效果，记录单分片压力、用户延迟、错误和回源次数；上线先覆盖可控业务范围，保留快速撤回方案。

## 交付与验收

输出要求：输出热点证据、读写分类、候选方案对比、流程与验证矩阵。结论必须说明获得的容量改善与牺牲的一致性或复杂度，未经实测的收益仅作为待验证假设。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

### 本条完成检查

- 热度结论有对应时间窗口和分片证据，读热点与写热点分别处理。
- 候选方案明确失效更新、旧值退出、回源压力和一致性代价。
- 测量覆盖延迟、错误、分片压力和回源次数，未经测量不写容量提升数字。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

来源（核验日期：2026-09-08）：
[阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

## 任务目标

请根据业务访问和数据生命周期设计 Redis Key、缓存策略及数据结构。

交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

缓存业务：从当前需求与代码选择一个有明确读取、更新和恢复来源的缓存对象；留空时优先整理已有 Key 的命名与生命周期，不凭空新增缓存业务。
工程与数据资料：读取 Key 构造、序列化、TTL、更新失效和回源代码，以及实体、查询、客户端依赖与 Redis 拓扑配置，自动归纳数据规模和版本边界。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 识别 Redis 是可重建缓存还是唯一存储，追踪每类数据的权威来源。
- 盘点 Key 前缀、实体与租户维度、数据结构、序列化格式和多 Key 操作。
- 读取创建、续期、删除、失效失败及缓存未命中的处理路径。
- 核对单机、哨兵、原生集群或代理模式，检查 hash tag 与集合增长边界。

### 可采用的默认处理

- 默认输出设计和兼容方案，不清理现有 Key 或改淘汰策略。
- 已有数据源、格式和拓扑优先；未知 TTL 不填固定值，以生命周期依据决定后再落值。
- 不默认引入 Tair 专有数据结构或不存在的租户维度；容量未知则按字节与增长量列估算式。

### 必须有依据的事项

- 权威数据源和数据丢失后的可恢复性不明时，不能定义自动过期或淘汰后的业务结果。
- 读取一致性与租户或组织归属未确定时，不给可能串数据或改变状态决策的缓存共享规则。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 无工程时交付 Key 字典、数据结构选择和生命周期表的可填写示例，明确哪些字段待业务确认。
- 提供首次回源、更新失败、格式升级、多 Key 限制和容量增长的验收用例。

## 执行要求

适用范围：开源Redis或Tair兼容场景；需要明确单机、哨兵、原生集群或代理模式。Tair增强数据结构不作为开源Redis默认功能。

检查 Key 与值的规模、序列化及集群分布，避免命名或 hash tag 造成倾斜。

检查步骤：
1. 明确Redis在该业务中承担可重建缓存还是唯一数据存储，逐项列出数据丢失、淘汰和节点故障后的业务后果，只有明确恢复来源后才能制定缓存失效策略。
2. 按读取、更新、批量访问和统计需要选择数据结构，说明单个对象与集合边界；估算一条记录、一个Key和全年增长的规模，不用条数代替内存字节数。
3. 给出Key命名表，覆盖业务前缀、环境、版本、实体标识及实际存在的租户维度；控制可读性与长度，避免把敏感信息直接作为可见Key。
4. 设计过期、续期、失效和淘汰后的处理，检查批量同刻过期是否会集中访问权威存储；缓存写入或失效失败时明确业务结果，不把命中率当作一致性保证。
5. 核对多Key操作在目标拓扑中的限制，以及hash tag能否导致大量对象聚集在同一分片；如需序列化升级，规划新旧格式的读取和退出顺序。
6. 生成正常读取、首次回源、更新失败、缓存缺失及容量增长的验证样例，观察延迟、回源量和内存变化；把文档建议阈值与当前业务实测限制分开展示。

## 交付与验收

输出要求：输出Key字典、数据结构方案、生命周期表、失败行为、容量估算与验收用例。字典需含示例、值定义、过期依据、增长上限、拥有模块和兼容策略，不填写未经测量的性能收益。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

### 本条完成检查

- Key 字典含值语义、拥有模块、过期依据、增长边界和新旧格式兼容。
- 生命周期说明缓存缺失、淘汰、更新失败与恢复来源，不以命中率代替一致性。
- 多 Key 与分片结论匹配真实拓扑，容量估算和实测数据清楚区分。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

来源（核验日期：2026-09-08）：
[阿里云《云数据库 Tair（兼容 Redis）开发运维规范》](https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

## 任务目标

请设计 MySQL 读写分离方案，并核对各类读取的一致性要求。

交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

读写业务链：从当前需求或事务后查询入口识别目标；留空时优先检查写后回显、状态确认和列表查询三类已有读取，按业务后果形成路由分级。
工程与路由资料：读取数据源、代理和驱动配置、事务代码、路由注解或拦截器及已有复制延迟记录，自动确认连接入口和数据库拓扑。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 沿写入提交到立即回读、跨请求查询和分页查询追踪连接与目标节点。
- 读取数据源选择、代理路由、事务绑定与连接复用机制。
- 查找库存、权限和状态判断使用的查询，关联业务可见性要求。
- 读取延迟、只读节点故障和主库压力的既有指标与降级代码。

### 可采用的默认处理

- 默认交付路由设计，不直接切换数据源或调整代理权重。
- 无法确定可容忍陈旧的读取保留现有路径；新候选不自动分流到只读节点。
- 延迟阈值和回流容量未测量时给观测及估算方法，不把阿里云代理规则套到其他实现。

### 必须有依据的事项

- 写后读取、权限、库存或状态决策能否容忍旧数据的业务要求不明时，不决定分流与延迟边界。
- 节点异常时允许拒绝、延迟展示还是回流主库没有业务依据时，不默认以成功空数据降级。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 没有实际拓扑时交付业务一致性分类、附前提的路由候选及写后读取测试设计。
- 没有可用数据库时给记录实际访问节点与可见时间的方法，故障注入仅列为隔离验证计划。

## 执行要求

适用范围：具备主库、只读实例或数据库代理的MySQL系统；阿里云代理路由规则须匹配实际版本，其他代理与应用自行路由应独立验证。

使用 RDS 代理分流读取时，核对事务、DDL 等请求的专门路由规则。

检查步骤：
1. 将查询按业务后果分类，分别记录必须看到刚写结果、可接受短暂陈旧和纯历史统计的场景，给出业务能接受的延迟边界，不能用统一延迟数字替代业务判断。
2. 绘制每条链路的连接入口和目标节点，包含事务、批任务、后台管理与故障处理；核对真实配置和调用结果，不能仅凭“只读”方法名称认定已访问从库。
3. 检查提交后立即查询、跨请求查询、分页和状态确认的行为，说明复制落后时用户可能看到什么；对状态决策、库存或权限判断列出需要的保证。
4. 比较代理路由、应用显式路由和保持主库查询的候选，明确驱动连接复用、事务绑定及路由切换的限制；不为了分担读压力把所有查询都切到只读节点。
5. 定义只读节点延迟过高、失联或容量不足时的降级，计算回流主库可能增加的压力；将限流、延迟展示和主库读取的业务影响分别说明。
6. 写入后读取、延迟注入、节点故障和恢复场景只在隔离测试环境或已明确授权的生产演练中验证，普通线上审查只采集已有指标；记录实际节点与数据可见时间；优化验收同时检查业务一致性和主库、只读节点的负载。

## 交付与验收

输出要求：输出业务一致性分级、路由表、失败处理矩阵、配置修改范围和验收用例。每条路由列出触发条件、目标节点、可见性要求及降级方式；新增数据库字段必须附详细中文注释。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

### 本条完成检查

- 每条路由对应触发条件、目标节点、事务限制、可见性要求和失败处理。
- 验证不只看读库负载，还核对写后可见、分页和状态决策的业务结果。
- 降级说明主库回流压力及限制，版本专属能力和未验证配置明确标注。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

来源（核验日期：2026-09-08）：
[阿里云《RDS MySQL：什么是读写分离》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/what-is-read-or-write-splitting/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

## 任务目标

请评审 Java 线程池容量和异步任务的可靠性。

以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

异步任务：从当前排队或任务失败问题选择执行器；留空时扫描自建线程池和 Spring 异步入口，优先检查共享池中具有业务副作用的任务。
工程与负载资料：读取执行器配置、任务代码、上下游资源、依赖与已有排队耗时指标和测试，自动判断平台线程、虚拟线程或其他调度方式。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 追踪任务来源、提交返回、排队、执行和完成通知，确认是否持久化。
- 核对核心线程、上限、队列、拒绝策略、线程名及所用版本的参数语义。
- 关联数据库连接、远程连接、锁和共享池任务，查找阻塞与相互拖慢的路径。
- 读取异常、取消、停机重启和重试处理，以及现有负载与完成率记录。

### 可采用的默认处理

- 默认只读评审，不直接扩线程、改拒绝策略或重启服务。
- 没有到达率与耗时分布时给测量方式、容量公式和附假设候选，不设固定最优线程数。
- 虚拟线程和响应式任务按实际实现另列边界，不机械套用传统池规则。

### 必须有依据的事项

- 任务是否允许丢失、接口何时算业务完成以及拒绝后用户应收到什么结果不明时，不默认静默丢弃或同步执行。
- 带副作用任务在超时、取消和重启后是否允许重试未定义时，不承诺可安全重复执行。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 无工程时提供任务可靠性分类、资源关系和容量估算表，以及排队满、下游慢和重启用例。
- 缺负载环境时交付现有配置的静态风险及所需指标，不把未压测候选作为可直接采用参数。

## 执行要求

适用范围：传统平台线程池与常见Spring异步执行器；虚拟线程、响应式调度器应另行评估，不机械套用旧线程数量建议。

明确线程池的资源边界，并为线程提供可识别的名称。

检查步骤：
1. 按业务列出任务来源、任务是否持久化、完成期限和失败归属，区分允许丢弃的通知与必须完成的业务任务；明确接口返回时任务处于哪个状态。
2. 绘制提交到执行完成的路径，标记线程池、排队、数据库连接、远程连接和锁等限制，找出共享池中可能互相拖慢的任务类型及调用方。
3. 根据到达率与耗时提出容量估算，写清假设、排队容忍时间和内存占用；资料不足时给测量方法与候选区间，不拍脑袋给固定线程数。
4. 逐项核对任务排队已满、执行超时、下游阻塞和提交失败时的行为，说明拒绝处理是否会让请求线程长时间阻塞、任务静默丢失或产生重复执行。
5. 检查任务异常、取消、应用退出和重新启动后的状态，验证调用者能否获知失败；若业务要求可靠执行，给出持久化任务与补偿的边界。
6. 设计平稳负载、突发负载、下游变慢及停机四组验证，采集排队时间、执行时间、完成率、拒绝数和资源占用；根据证据逐项调整，保留回退配置。

## 交付与验收

输出要求：输出任务分类、资源关系、参数建议表、失败处理矩阵及验证计划。参数建议必须含当前值、依据、候选值、预期影响和回退条件，不把未压测值写成最优配置。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

### 本条完成检查

- 任务分类明确完成期限、失败归属、持久化与丢失边界。
- 参数建议关联当前值、资源上限、推导条件及拒绝影响。
- 验证排队、完成、拒绝、异常和重启后的任务结果，未测容量保持待验证。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

来源（核验日期：2026-09-08）：
[阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。