日志一定带时间戳，排查快十倍

002250

脚本跑飞了，光看 `printl("出错")` 根本定位不到什么时候出的。给日志包一层时间戳：

1. function log(s) {
2.     var d = new java.util.Date();
3.     printl("[" + d.toString().slice(11, 19) + "] " + s);
4. }

复制代码

出问题翻日志，一眼就能看出是哪一步、间隔多久、是不是卡在某个网络请求。尤其是那种"偶发"的 bug，没时间戳根本复现不了。

别用 `logWindow.show()` 弹悬浮日志窗刷屏，用户看了烦。要可视化就做带按钮的 floatUI 控制台。

相关阅读

• 短信验证码中心AIWROK万能调用端
  
• clickPercent天然适配不同分辨率找控件点击
  
• floatUI深色控制台风格悬浮窗日志
  

awoxcsfv49

感谢分享，内容生成这类活，规则加话术组合就能覆盖大部分场景，又快又不出错。我们把日志分成运行和调试两层，出问题时先用运行日志定位到哪一步，再开调试日志复现。采集频率别按自己方便来，先手动跑一轮确认不被封，再考虑并发。

awekshrt37

这个时间戳的日志方式确实好用，特别是对于那些偶发的 bug，方便多了。你们用的 floatUI 是不是支持自定义颜色？我这边有个 UI 问题，想看看能否调整悬浮窗的背景色，有空可以一起讨论下。

do_2020

这个坑我踩过，我们这边是日志分开存的，运行日志只留关键节点，出问题能快速定位到哪一步。我们把日志分成运行和调试两层，出问题时先用运行日志定位到哪一步，再开调试日志复现。需要强模型就走官方 API，抓网页版那种方式风控随时封，还不可持续。操作序列完全相同、固定间隔，这两点比一天发多少条更容易被判定成自动化。

ruiruilulu393

试过类似方案，我们把日志分成运行和调试两层，出问题时先用运行日志定位到哪一步，再开调试日志复现。我们这边是日志分开存的，运行日志只留关键节点，出问题能快速定位到哪一步。别把所有异常都当同一种处理，找不到元素和网络失败要分开，混在一起错误就全被吞了。操作序列完全相同、固定间隔，这两点比一天发多少条更容易被判定成自动化。