虽然这个建议看似合理，但实现起来确实有点困难，大概率是没办法了。
1、所有用了私有变量的项目，加一个$尾巴，工作量应该不大。 总不至于整个项目全用的私有变量。
2、这个$是引擎代码里加的，动态改起来比较难，并且成本高。
3、当你访问的变量带有 $ 尾巴时，说明引擎并不推荐访问 ，后面的版本中有可能随时变，就得注意了。
我觉得要从两方面解决。
1、加上开关（这个内部版本已经有了，下一次社区版更新就会有）
2、大家把访问到的私有变量和需求都多说说，推进引擎接口的完善。这才是长久的路线。
恩，我也只是提出建议，其中难度并不清楚，如此的话，也只能翻阅代码进行修改了。
嗯嗯。 本质上来说，还是想多看看大家的需求，这样引擎好新增一些应对这些需求的接口。
是的，如果私有变量都要保持兼容的话，那做一些优化重构，举步维艰。会把问题弄得复杂化。不利于后续重构与维护。
这次刚好借此机会，把用户的潜在对引擎私有接口的修改暴露出来。否则之前官方都不知道哪些接口不满足需求导致用户需要hack。这样也可以推进公有接口的可用性。否则用户魔改私有接口完全不会反馈回引擎。因为魔改后可以跑，完事。哪有时间反馈回馈给社区。
好的，谢谢。
这个过程是这样的：
所以最终找到了私有属性上，这中间有个信息差就是不知道有提供的方法，然后过程中偏差了方向，导致结果偏差了。
有没有可以代替 cc.js._nameToClass 的接口或者可以获取到 bundle 中所有被使用的 ccclass 类型的方法？
这对 bundle 代码热更来说很重要，因为需要在加载新的 bundle 时对 bundle 内所属的 ccclass 执行 cc.js.unregisterClass
或者引擎支持 bundle 代码热更？这是我自己实现的，并不复杂
引擎代码是开源的，文档上没有，可以直接翻代码看的。
用 console.log(spine) 这个来找接口不是个准确、直观的好方法。
检查了下自己使用的私有属性
cc.EventTarget 中的 _callbackTable，因为扩展 EventTarget 需要拿到监听列表
jsb[“onError”]，已废弃，未公开接口，用于错误监听
window["__errorHandler"]，用于错误监听
cc.EventTarget 中的 clear，用于清理所有事件，功能正常但是不知道为什么不是 public 接口
cc.Asset._uuid，已废弃，用于作为资源索引 key，是否有替代方案？
我这里重申一下引擎这次修改的原因就是想减小包体。包体问题在小游戏平台和 web 平台是敏感的。所以这次的就是关注了这里的需求。而且这次的优化也是针对私有变量的处理，私有变量本来就是不允许外部访问的，是因为语言的限制导致了大家可以随意访问。
至于引擎功能不完善而导致非要访问私有变量，这部分需要根据反馈让引擎看怎么修改合适。而不是通过直接访问私有变量的方式。访问私有变量就得做好准备会被修改的可能。
引擎既要保持兼容性，还得减小包体，提升性能等工作。如果连私有变量和私有函数，以及没导出的代码都要保持兼容的话，那么引擎只能是不断加代码了。因此，后续我们还可能对私有变量和私有函数进行重构。可能不是因为包体问题，可能是逻辑的优化，性能的提升等。
可不可以通过用户可配置的表，来指定 不被压缩的 私有属性？
赞同，本来私有函数/属性就是不建议公开使用的
这在ios上审核，甚至调用私有函数都可能会下架
既然自己要强行使用用私有函数/属性，就得自己埋单
_nameToClass 尽管是下划线开头的，但是 export 出去的属性，不会做压缩处理。
我转到这了，可以在这里讨论，主要的是接口已废弃，但是没有新的接口可以代替
export class CallbacksInvoker<EventTypeClass extends EventType = EventType> {
/**
* @deprecated since v3.5.0, this is an engine private interface that will be removed in the future.
*/
public _callbackTable: ICallbackTable = createMap(true);
这个虽然是下划线开头，但之前定义了是 public ，不会做压缩处理。
JSB 相关的调用，不受影响
CallbacksInvoker 中是有的，EventTarget 中有 removeAll(keyOrTarget)，但是没有 clear，我估计是当时定义 interface IEventified 的人漏了 clear。
有公有接口可以用：
/**
* @en
* The UUID of this asset.
*
* @zh
* 资源的 UUID。
*/
get uuid (): string {
return this._uuid;
}
后面引擎内部的私有属性都用#申明吧，别依赖private了。这样就无法滥用了。
好的，我们会评估一下。感谢反馈。
支持，总不能既要又要，本来私有变量就不应该随意hack，hack同时应该要向引擎组提公有需求，为引擎完善出一份力，hack完实现了，又不提issue，让引擎组在新版本支持，那就自己负责就好
有没有可能，那个属性/函数，不应该设置为私有的
说到点子上了
这样把hack的路彻底堵死了，那估计开发者要吵翻天了。 