Unity DOTS / ECS卡顿时先查哪里DOTS 项目出现卡顿时先区分是每帧都慢还是偶发的一帧尖峰。前者通常和遍历规模、数据布局或 Job 并行度有关后者更常见于结构变化、同步点、资源加载或容器分配。把两类问题混在一起看只会让 Profile 结果越来越难解释。先从 Timeline 找到等待者在 Profiler 的 Timeline 中先确认主线程是在执行系统还是在等待某个 Job 完成。若主线程长时间停在Complete不要立即增加 worker 数量先找是哪一个系统需要主线程读取 Job 的结果。很多时候是调试代码、托管组件访问或错误的更新顺序提前制造了同步点。给每个热路径系统注明读写的组件和所属更新组。例如移动系统只读输入与位置、写速度碰撞系统读取位置和碰撞世界、写事件缓冲。这样 Burst 与调度器才能判断哪些 Job 能并行评审也能发现两个系统对同一组件的意外写入。结构变化集中处理在遍历实体时直接添加或移除组件会让实体存储重组并可能导致这一帧出现明显尖峰。把这类操作写入EntityCommandBuffer在约定的回放点统一执行。若某个系统每帧都创建短生命周期实体先确认能否复用实体或把状态改为 enableable component再考虑扩大对象池。结构变化发生后要检查它是否触发了不必要的查询重建。测试场景可以固定实体数量分别执行“只更新数值”和“新增/删除组件”两条路径两者的帧时间差异能够帮助定位问题是否来自结构变化而不是普通计算。Native 容器和依赖要成对出现传给 Job 的NativeArray、NativeList或自定义容器需要明确谁创建、谁释放、哪个JobHandle表示写入完成。场景切换和系统禁用时先完成仍在使用容器的 Job再释放资源。不要只在正常OnDestroy路径清理异常退出或禁用再启用同样需要覆盖。回归用例至少包括空查询、批量实体增删、系统禁用后重启和场景切换。打开 Jobs Debugger 与安全检查确认没有未完成依赖、越界访问或重复释放。每次改动记录实体数量、系统顺序和采样方式换 Unity Entities 版本后再以相同场景比较不把一次 Profile 结果外推到所有关卡。如果尖峰只在首帧出现额外记录世界初始化、SubScene 加载和首次 Burst 编译的时间。它们可能需要单独的加载界面或预热步骤却不应被误判为战斗系统的持续性能问题。定位清楚后再决定优化代码还是调整加载时机。对每次优化保留修改前后的同场景采样记录关闭安全检查后的差异仅用于定位不把它当作正式性能结论。发布构建仍应在目标设置下验证功能正确性。必要时由另一名开发者复验。