Unity DOTS/ECS 任务超时怎样重试才不污染状态重试必须有次数、退避和幂等约束并能被上层取消。 这篇只讨论可落地的拆法按数据访问模式划分组件和系统而不是按传统对象层级照搬。热路径的组件保持 blittable托管引用、资源加载和展示逻辑留在明确的桥接层。先定边界为每个系统写清读写组件、更新组和依赖关系。结构变化集中到 EntityCommandBuffer避免在遍历过程中直接增删组件Job 中传入的 Native 容器要有清晰所有权。不要用一句“模型会处理”或“框架会处理”掩盖状态变化。把输入来源、允许的副作用和异常返回写进接口说明开发、测试和内容制作才能使用同一套判断标准。实现时盯住三个点状态归属谁创建、谁更新、谁负责清理要能从代码和配置里找到答案。异步边界请求、任务或渲染资源都需要超时、取消和完成回调重复调用不能把旧结果覆盖新状态。可回退性把开关和默认行为放在调用边界失败时返回受控结果不把半成品继续传给下游。这样安排的好处是每次改动都能定位到一个责任模块。问题出现时先看边界记录再改实现不必靠猜测追踪整条链路。验证清单打开 Jobs Debugger 与安全检查覆盖空查询、实体增删、场景切换和系统禁用再启用检查依赖是否完成、容器是否释放以及同一帧的写入顺序是否稳定。检查配置、资源和接口版本是否随构建物一起发布。对每个降级分支确认用户仍能完成当前操作且状态不会被错误写入。把这次发现的前置条件补到验收样例避免下次只重复同一类检查。收尾DOTS/ECS 的重试必须服从状态所有权旧任务不能在新一帧回写结果。
