Cocos 项目越写越乱，我按三条线收拾

2026-09-09 Cocos Creator,工程结构,代码组织,重构

工程乱到一定程度，症状不是报错，是我不敢改：一个颜色改了，另一个界面跟着变；想删一个脚本，得先搜哪些场景引用了它。Cocos 项目越写越乱怎么办，我后来的做法是按三条线分开收拾，而不是整体重构一遍。

一、真实结论：乱在「引用关系」不在文件多少

我那个涂色模板总共没多少文件，依然乱。

原因是我早期把「谁引用了谁」完全交给编辑器，场景里拖了一堆引用，脚本里又硬编码了一堆路径。文件少但关系密，照样改不动。

三条线分别管：资源从哪来、逻辑归谁、界面怎么搭。分清楚以后，改动开始有确定的影响范围。

项目最开始只有一个场景，随便放都行。

加第二个场景的时候我没有建目录，直接把新资源丢在同一个文件夹里。到第三天做配置界面时，我已经分不清哪张图属于哪一关。

真正让我下决心收拾的，是我想复用第一关的一部分到第三关，结果发现它们缠在一起，拆不出来。那天我停了半天没写新功能。

不按类型分，按使用时机分。首屏用的、某一关用的、全局共用的，各放各的。

这样分的好处是，包体那块要砍谁一眼就看出来。我后来打包时能很快定位冗余资源，靠的就是这条线。

具体动作：把资源目录按首屏 / 关卡 / 公用三层重排一次，重排期间不要顺手改功能。

一个脚本只允许一类人去改它。界面的归界面，数据的归数据，中间那层专门负责转换。

这条线最容易破。急着加功能的时候，人会把数据处理的代码写进界面脚本里，然后这个脚本就再也拆不开了。

判断方法很土但有效：如果一个脚本改起来你总是要担心影响别处，它就跨线了。

每个界面应该能单独跑起来看，不依赖前面走过什么流程。

做不到这一点，说明界面和数据绑太死。我后来给每个界面做了一个直接进入的入口，调试成本降了不少。

做对的是我没有选择推倒重来。推倒重来的代价被低估了，尤其是项目已经能跑的时候。

做错的是收拾得太晚。第一次发现两张图分不清归属时就该动手，而不是等到拆不出来。

另外我也做错了一件事：收拾过程中顺手改了功能。结果那次改动出了问题，我分不清是整理引入的还是新功能引入的。

这套分法能不能复制？能。它不需要项目有多大，也不需要换引擎。

唯一的门槛是你要停下手上的新功能，专门花一段时间整理。这段时间不会立刻产生可见成果，所以最难下决心。

我给自己的规则是：一旦出现「不敢改」的感觉，就停下来做一轮。别等它变成「改不动」。

Q：Cocos 项目越写越乱，需要整个重构吗？

A：大多数时候不需要。先按资源、逻辑、界面三条线把目录和引用关系理顺，比推倒重来便宜得多。

Q：整理期间要不要继续开发新功能？

A：建议不要同时做。混在一起出问题时，你分不清是整理引入的还是新功能引入的。

Q：小项目也要这么分吗？

A：要，但可以更粗。三条线分清楚就行，不用把目录做得像大公司那样深。