请教一下，该工具在生产环境实际使用的最佳实践

[Damon0820]

作者所提到在测试环境，测试人员和开发人员不在同个地方，使用此工具有助于排查问题。
想了解下，生产环境是否也适合使用该工具排查问题？最佳实践如何。

1. 考虑到全量生产用户加载此sdk，对用户本地性能可能有影响，并且ws服务端接收的客户端连接数可能很大。所以是否要结合灰度白名单方案，给上报问题的用户单独加载sdk。
2. 项目若已经接入了错误监控系统。相较于错误监控系统，接入该工具，在排查生产问题时，哪些场景下有优势。

[Nice-PLQ]

生产环境适合使用该工具，目前我们已在生产环境使用，效果不错。
1、不能全量用户加载sdk，只能给需要调试的用户单独加载sdk。非调试用户加载sdk是多余的。
2、对生产环境而言，该工具可以认为是错误监控系统的辅助工具。一般来说，监控系统最多用的是看js error。但考虑到一般js都会发布在不同源的cdn，这就会导致在ios下无法获得到具体的错误详情（Script Error.），具体可查阅https://bugs.webkit.org/show_bug.cgi?id=132945。另外该工具能远程查看和操作DOM、实时预览用户页面，这些能力常规的监控是不具备的。当然，前提是需要尝试联系上用户，使其重新打开页面，建立远程调试连接。

以我自身为例，业务是技术栈是同构直出，在对需要调试的用户进行染色后(其实就是白名单机制)，在node层会对html产物进行一次处理。比如，在html的head中注入sdk.js，同时修改link[ref=stylesheet]、script[src=xxx]的标签，是其内联。
后续尝试联系用户，再次打开页面后，就可以远程调试了。

如果是没有node层的，也可以在nginx中对网页html内容进行处理，比如ngx_http_sub_module等

[Damon0820]

感谢大佬详细解答👍
总结一下大佬的回答：

1. 在需要的时候，只给白名单用户加载sdk，并对html做处理。
2. 远程调试工具作为错误监控系统的辅助工具，有一些增强的能力，是监控系统没有的，对解决问题有帮助。

对于第2点的拓展：
大佬遇到哪些实际问题，是监控系统和用户录屏不好解决，但是使用了远程调试工具的增强能力后，给予了巨大帮助后才定位到问题并解决的。感觉这种场景最能体现该工具的价值，大佬有空举几个实际案例分享一下？目前比较直观的是调试样式问题会有优势，因为可以审查元素和样式。

[Nice-PLQ]

感谢大佬详细解答👍 总结一下大佬的回答：

1. 在需要的时候，只给白名单用户加载sdk，并对html做处理。
2. 远程调试工具作为错误监控系统的辅助工具，有一些增强的能力，是监控系统没有的，对解决问题有帮助。

对于第2点的拓展： 大佬遇到哪些实际问题，是监控系统和用户录屏不好解决，但是使用了远程调试工具的增强能力后，给予了巨大帮助后才定位到问题并解决的。感觉这种场景最能体现该工具的价值，大佬有空举几个实际案例分享一下？目前比较直观的是调试样式问题会有优势，因为可以审查元素和样式。

我这边的更多的是应用于一些用户投诉的场景，这种在监控系统不一定能查到具体的报错信息，比如前面提到的Script Error.的问题，所以我们会去联系用户，让用户再次打开页面，通过远程调试去定位。
除了协助线上定位问题，还有一些开发场景下也可以用远程调试，比如我们web页面可能在一些第三方客户端的WebView有问题，这种用远程调试可以方便我们定位。