犯的错
缺乏流程
应该按照如下流程去做，稳扎稳打：
别一上来就钻细节
记住：排查问题的初期，别看代码！
因为一上来你就钻细节，很容易跑偏，被细节带着走，进而忘了问题和目标本身是什么。
如何避免上来就钻入细节，这里有2个技巧：
- 先逮着问题反馈方，问10个问题
- 自己反复使用和测试出问题的页面，详见下一个章节
没有明确现象和问题的范围域
排查问题和架构设计一样，都应该遵循这个原则：自顶向下，逐步求精。
排查问题时，先别管其他的，就点点点，操作N次，明确问题出现的规律和情形，寻找差异点，并且在加入自己的逻辑分析后，确保你的分析逻辑和现象能对得上、说得通，本质上还是得有逻辑性。
比如这次的初始验证，就应该考虑到如下这些因素，逐一排除掉：
- 确定是业务方 or 我们 or 行情图组件的问题：我们单独的图表示例有没有问题？单独的行情图示例有没有问题？
- 只有行情图叠加标签出问题，还是所有行情图都有问题？
- 非行情图有没有问题？
- datazoom和overlap有没有问题？
- 切换主题有没有问题？
- 是具体某个主题有问题，还是所有主题都有问题？
这样逐一通过现象验证后，短时间就能把问题缩小到一个很窄的范围，极大加速调试效率。
为什么缩小范围域至关重要：因为假设问题域中的变量为 n，那么可能性就是 n x n，这样你排查起来就是打地鼠，难以确定原因。
过度依赖AI
不要上来就直接让AI去分析，这种情况下，你不是让AI分析原因，完全是赌博，让AI在瞎猜。
我们应该先通过现象+自己的经验，进行逻辑分析，缩小范围后，给AI指定明确的上下文，让其在小范围内进行确定性的、合乎逻辑的分析。
我们在调试过程中的作用，就是给AI缩小范围+提供上下文，解决AI看不见的问题，可以理解为：
- 问题是景色
- AI是盲人
- 我们是医生
我们不断治疗AI(给其提供上下文、限定范围)，最终让它恢复视力，看到问题的本质。
未设置AI的递归出口
当同一个方向，你让AI修改了N(比如N = 3)次，如果还是没搞定，就停下来，纯由人工介入进去审查一下，帮助AI纠正方向，再进行后续的尝试。
因为如果尝试了N次也没搞定，那么很可能这个方向是错的，继续下去，只会在错误的道路上越走越远。
未构建高效的调试
比如：
- 构建易修改和发布、与其他无关因素解耦的独立测试页面
- 代理线上的资源到本地
- 简化build脚本，让构建从几分钟降低到十几秒
否则这些东西，随着你调试次数的增加，其成本是递增的。
如何快速构建分析思路
符合逻辑 + 经验
很多问题，我们其实是可以通过现象+猜测的方式来快速缩小范围的。
比如这次的现象：
1、进入页面就卡死：第一个想到的肯定是死循环、内存爆了、同步加载机制有误(比如在图表实例初始化之前调用了实例方法)
2、切换主题卡死：第一个想到的是对象未销毁、重复注册/初始化
二分法
当实在不好确认，或者影响因素太多时，可以通过二分法来缩小范围。
这个办法笨，但是稳。
做好记录
如果问题比较复杂，调试时间较长，到后面你会记不住自己尝试的内容。因此将过程和结果记下来，很有助于帮你进行分析。
1
2
3
4
5
6
7
8
9
| 我弄了不同版本的链接，都是会出问题的：
https://t.zhouchangju.com/test/tmp/0.12.0/examples/index.html?case=行情图叠加标签
https://t.zhouchangju.com/test/tmp/0.14.0/examples/index.html?case=行情图叠加标签
https://t.zhouchangju.com/test/tmp/0.15.0/examples/index.html?case=行情图叠加标签
说明可能和我们这个版本迭代没问题
然后我试了下折线图，没问题，那说明问题在于行情图上。
我们可以搞个单纯的行情图试试，看是行情图本身的问题，还是结合我们的组件后产生的关联影响。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| 行情图：
ifind切到白色，没问题；白色切到黑色，没问题；黑色切到白色，【出问题了】
黑色切到ifind，【出问题了】
行情图叠加多指标折线：
黑色没问题，切到白色出问题了
ifind切到白色，没问题；白色切到黑色，没问题；黑色切到白色，【出问题了】
行情图叠加柱状图：
黑色没问题，切到白色出问题了
ifind切到白色，没问题；白色切到黑色，没问题；黑色切到白色，【出问题了】
ifind切到黑色，没问题；黑色切到ifind，【出问题了】
行情图叠加标签：
ifind切到白色，没问题；白色切到黑色，【有问题】
ifind切到黑色，【有问题】
基本得出结论：
1、和不同类型的KLine没关系
2、白色没问题，黑色有问题
接下来对比不同主题风格的差异点。
|
Prompt
明确相关的文件，缩小上下文范围：
1
2
3
4
5
6
7
8
9
| 这个组件库的
@src/layer/preset/hxKLineAndTag.ts 是对一个第三方行情图组件的封装，然后通过
@examples/index.js 编写了一个使用示例
我们发现这个示例在特定的iOS版本上面打开，会卡死。
不用我们组件库，单独写一个行情图组件的示例是没有问题的。
我们这个组件库下面的其他封装的组件，也能正常渲染，没有问题。
请基于这2个文件以及其他相关的文件，帮我分析下我们这个封装的行情图组件卡死的原因是什么？
|
补充上下文：
1
2
3
4
5
| 额外再补充一个信息：
主题选择iFind-light没问题
从其他主题切换到iFind-light也没问题
默认渲染AI-F10-light主题会崩掉
从其他主题切换到AI-F10-light主题也会崩掉
|
1
| 我初始就默认渲染这个行情图组件，没有执行任何切换操作的情况下，也会卡死，请结合这个情况再分析下。
|
1
2
| 经过我的测试，发现是ai-f10的主题配置文件(examples/config/ai-f10/token.xxx.js)中dvHXKLine.constants的配置导致的这个问题，我删除这部分配置，就没有问题了；请帮我分析下，具体是这里的哪个配置导致的问题，为什么会导致这个问题？
而且这个问题很奇怪，在2个相同系统版本(iOS 15.0.2)的手机上，一个有问题(iPhone12 mini)，一个没问题(iPhone 12)，这是为什么？
|
1
| 另外我发现个问题：如果我们的组件库默认就渲染ai-f10的light主题，即使里面带有constants相关的配置，也能正常渲染出来；但是一旦我切换到其他主题，比如ifind的主题，页面就会挂掉。
|
编写测试用例：
1
| @examples/config/ai-f10/hxkline.html 是针对这个KLine组件写的一个示例，请将项目中的这些主题常量注册到这个文件中，便于我验证下到底是不是KLine组件的问题。
|
调试环境优化：
1
| npm run build 目前构建耗费的时间很长,而目前我在调试,只需要构建bundle.esm.js文件即可,其他的暂时不用;请帮我优化下相关的构建逻辑,加速构建速度
|
追溯根本原因：
1
2
3
| 我发现如果没有你这个修改，初始进入页面是会加载很久才能出现K线图的，然后页面也会卡死；而加了你这个修改，初始加载就不会有问题了。
你这个修改只是为了避免切换主题的重复加载，按理说第一次总是会加载主题的，为什么有没有你的修改会出现这个差异呢？
请帮我分析下这是什么缘故？
|
整理文档：
1
2
3
4
| 这次整个问题排查过程的文档，我都移动到 @docs/troubleshooting/ios-bug-analysis
目录下了；你帮我审核分享下这下面的文档，看有没有错误的、不合理的、可优化的，帮我优化整理精简下；
另外之前的一些分析中，如果有虽然和这个问题无关，但是确实客观存在、可能引发其他问题的内容，也保留下来，作为后续待优化的内容。
你先给出分析结果，待我确认后，再修改文件。
|