687c4535f8
P0-1 (limits.go): Allow()方法改为全程使用写锁保护counters map读写，避免RLock写入时的data race P0-2 (ticket_workflow.go+ticket_handler.go): Assign/Resolve/Close操作先查询ticket存在性和状态，返回明确的CS_TICKET_4001/CS_TKT_4002/CS_TICKET_4092/CS_TICKET_4093错误码，handler根据错误前缀路由HTTP状态码 P1-1 (ticket_store.go): 移除GetStats中3处手动rows.Close()，只保留defer Close()
2.0 KiB
2.0 KiB
Internal 目录规则
目录定位
internal/ 承载系统内部共享能力、领域公共逻辑和跨模块复用部件。这里不是“放不下就往里塞”的杂物区，而是整个项目长期可维护性的关键层。
在这里的设计失误，通常不会立刻以接口错误暴露出来，但会持续放大耦合、重复、语义漂移和后续改造成本。
第一原则
-
共享能力必须有明确边界。 只有真正跨模块、稳定、可复用的能力才应该进入
internal/。一次性逻辑或只服务单一模块的细节不应提前上收。 -
语义稳定优先于短期省事。 进入共享层的结构体、接口、错误码、辅助函数，默认会影响多个模块，命名和行为必须克制且一致。
-
不做伪抽象。 如果抽象只是在把一段简单代码包成更难理解的通用层，那不是改进。
-
内部共享层也必须可验证。 即使不直接对外暴露，也要优先可测试、可推理、可替换，而不是隐藏复杂度。
适合放进这里的内容
- 多模块共享的基础类型、辅助库、公共校验
- 跨模块一致性约束
- 稳定的领域公共模型
- 明确复用价值的中间层能力
不适合放进这里的内容
- 单一服务的临时逻辑
- 只为减少 import 路径而上收的代码
- 未验证是否真的复用的“预抽象”
- 模糊归属、未来可能会用到的占位代码
变更要求
- 修改共享结构前，先确认受影响的模块集合
- 公共接口或类型变更时，必须同步检查所有调用方
- 如果一个改动会提升复用性但降低可读性，默认优先保护可读性
验证要求
- 至少验证直接调用方
- 涉及公共类型、错误语义、工具函数时，尽量补单元测试
- 不要只改定义，不验证实际使用行为
禁止事项
- 不要把
internal/变成“无法归类代码”的默认落点 - 不要在没有两个以上真实调用场景时提前抽共享层
- 不要让共享层承载模块专属业务语义