沿用现有 Compose、环境变量、监听端口、持久化目录、Token 和 API 版本。已部署实例可按原有方式更新镜像，不需要修改客户端或迁移数据库。认证、用户限额、域名归属策略、提交身份和逐域名提交方式保持一致。
- 同一规则文件的并发读取与解析共享进行中的任务。文件版本参与缓存键，较早的读取结果不能覆盖较新的写入结果。
- GitHub 成功提交后，使用响应中的文件 SHA 更新本地快照。响应缺少文件元数据时重新读取，不用提交 SHA 代替文件 SHA。外部写入引起的冲突仍刷新文件并重试。
- Contents API 省略大文件内容时，按精确 SHA 读取 Git Blob。非空文件的内容缺失或编码异常时拒绝写入，避免把已有规则当成空文件覆盖。两种读取都使用现有的仓库内容权限。Contents API、Git Blob API
- 相同域名和查询类型的并发 DNS 查询共享上游工作。A、NS、多解析器证据和解析状态分类分别合并；是否使用中国 ECS 也参与查询键。解析器一致性要求和已有缓存时限不变。
- 一个调用者取消时，其他调用者继续等待共享结果。全部调用者取消后，回收共享任务及其解析器子任务。
- 延后队列在内存中维护待处理键索引，普通请求不再打开队列数据库。索引命中时仍核对持久化记录，成功写盘后才确认接管。
- HTTP 入口最多同时处理 128 个提交。超出容量时返回现有的
HTTP 503、status=temporary_error，并附带Retry-After: 1；不会确认尚未接管的记录，也不会消耗该请求的用户配额。客户端沿用原有重试逻辑。
Token 每次仍查询当前启用、版本、到期和隐私同意状态，不缓存授权结果。GitHub 写入继续串行处理，并保留 SDK 的请求间隔和退避。GitHub 建议串行请求并在写操作之间暂停，以避免触发次级限流；提高本地并发不能消除这些上游限制。GitHub API 最佳实践
数据文件每次复检仍计算 SHA-256。完整语义校验通过后，把校验版本、数据类型和统计量保存在原有 .meta.json 中。只有文件哈希、大小、类型和校验版本都匹配时才复用统计量；文件变化、元数据缺失或校验规则变化时重新校验。
相同内容的重复下载可复用已验证的统计量。新内容仍完整校验，并执行原有异常缩减保护。元数据字段自动维护，旧版本会忽略新增字段。