少在意这些虚幻的噱头，不可否认功绩是有的，但是瑕疵也不少，而且更多时候是绕不过去的瑕疵，甚至是不知何年何月能修复的瑕疵
你再仔细看一次
开不开倒车我无所谓，能不能给支个招，让原生jsc不要合并代码，能分行，这样能追踪匿名方法，就像2.x版本那样
哈哈哈哈，Guo 啊，你能得到这个头衔，不可否认你功绩是有的
你心态是真的好
这个title可有违反广告法的嫌疑 :doge:
建议换成东半球冠军 
这个编译选项能解决你的问题吗
楼主是cocos creator真爱
里面的所有选项都测试了，而且还看了cmake，还看了引擎，发现引擎里的pack tool应该是编辑器的逻辑调用的？比如ios的pack tool里的方法，没找到是哪里调用的过来的，所以我没能解决。
2.x的原生，会生成js backups (useful for debugging)文件夹，里面的代码混淆后，是这样的，
是有分行的，这样的话，如果玩家的手机报了错，能根据报错的行数找到原因，就算是匿名方法，根据行数也能分析个八九不离十。
而3.8就太离谱了，混淆后的代码是这样的，
每一个system.register，是一行，比如第二个红圈内，这么多代码算作一行。有匿名方法报错了，那么报错信息只能追踪到 index.jsc 行2，只能知道是哪个类报错了，而有的脚本足有几千行，而混淆后被认为是一行，根本就无法追踪。
在应对大型项目，脚本几百行几千行甚至破万的情况下，这样的混淆方法科学吗？是压出来很小，7MB的原代码压到2MB多，但我原生真不在乎那几MB大小啊，你哪怕70MB我也不在乎的啊
对比了一下，3.x 确实使用压缩率更高的构建工具，这个确实也是出于包体考虑，
可以尝试使用 beautify 这个 vscode 插件，重新 format 展开一下看看
报错的行数也是指向一整个类，而不是具体哪行，vscode就算展开了，依然没法知道是哪句不对，异步的操作挺多，匿名方法也是无法避免
我理解这个应该跟 jsc 加密没关系，估计构建 release 包的时候就会被混淆了，可以考虑用 sourcemap
恢复原始信息
构建的时候可以把 sourcemap 勾选上，写个简单的 node 脚本尝试解析一下 sourcemap 应该可以定位到源码里的具体行数
// node 脚本
const fs = require('fs');
const sourceMap = require('source-map');
// 报错信息中的行号和列号
const errorLineNumber = 15;
const errorColumnNumber = 361;
// 读取sourcemap文件内容
const sourcemapContent = fs.readFileSync('./index.js.map', 'utf-8');
// 解析sourcemap
(new sourceMap.SourceMapConsumer(sourcemapContent)).then(consumer => {
// 映射错误位置
const originalPosition = consumer.originalPositionFor({
line: errorLineNumber,
column: errorColumnNumber,
});
console.log('Error occurred at:');
console.log(`File: ${originalPosition.source}`);
console.log(`Line: ${originalPosition.line}`);
console.log(`Column: ${originalPosition.column}`);
});
3赞
这个插件弃用了
应该是停止维护了，基本功能还能用，用来分析混淆后的代码，还是挺方便的
有图有真像，支持
1赞
还有 windows 上的图标和快捷方式名，图标锯齿很多，左右两边可能还没对称，快捷方式命名突出一个原汁原味
4赞
收到，2.0.2 的时候重新导出一下图标
不要让用户给你提bug.要自测
没有列数么
还有名字呢,太长了,可以直接叫Cocos. 而不是CocosDashboard_2.0.0 显示太长的名字本身就显示不全,也不利于记忆和辨别. 具体的版本号可以在面板里看.
2赞