将 GameManager 做成单例模式，在 Cocos Creator 这类游戏开发中，是管理全局唯一状态和提供公共服务的最实用、最普遍的架构选择。它的好处和最佳实践可以用下图清晰地概括：下面我们来详细解读每个核心优势。📝 核心优势详解1. 唯一数据源，杜绝状态混乱这是单例模式解决的最根本问题。游戏中有很多数据必须是全局唯一且统一的，例如：玩家分数、金币数游戏状态：正在运行、已暂停、已结束当前关卡、游戏配置 如果这些数据分散在不同的脚本或节点中，很容易出现不一致（例如 UI 显示的分数和实际存储的分数不同）。单例 GameManager 确保了整个游戏都从它这里读取和更新这些核心数据。2....

最近也面了好几家公司字节-抖音研发：一面挂，脏面评了B站-直播测试：面试官觉得我服务端测试经验不足，半小时结束，手撕都没出百度acg质量部：面试官不开摄像头，一直盯着我那没意义的项目的一个点狠狠攻击，半小时结束，无手撕，应该是 kpi 面了快手-商业化：一面 50 分钟大部分在问实习，因为上一段实习和这个面试的很垂直，又问了一些数据库和 redis，消息队列的八股手撕：力扣 80 删除有序数组中的重复项当天晚上约二面隔一天二面：25 分钟问了实习，一道三数之和，反问后结束，面试官说会稍微看重一点代码能力半小时后 hr联系口头 offer，当天下午发 offer快手效率这一块因为快手这个业务组和我上一段实习，非常垂直，面试起来也比较得心应手吧，进度推的也很快最近期末周，又要复习，又要面试，回学校前，还在上班，这三个叠一起，真的感觉忙不过来了，再加上一开始的字节和 B 站秒挂，很大程度上给我了一些打击，不过好在挺了过来继续加油吧附：之前一直投快手，简历挂了两页

#围观美财长回应斩杀线甩锅# 2025年年中，一个风和日丽的周五下午，我带着美丽的心情，在公司，完善项目网站的一个功能，查看数据库的时候，突然发现一张表里的数据很奇怪。那是个业务数据表，按理说在几秒的时间内，不应该出现三条同样的经办数据（一个客户不可能在几秒内，做三次业务），可偏偏，很多用户数据都出现了这种情况。关键还是正式环境，客户是政府单位的，后面要是稽查起来，不敢想了。虽然不是我做的功能，但还是给我吓的，尿不湿都湿了。 我赶紧给项目经理说了情况，结果就被扣了帽子，说我发现了，怎么不赶紧改，还问是什么原因？直接给我干懵了，我是赶紧看那个功能代码呀，那会是真的害怕了，框框一顿看，后面才发现了...