网站调试与反调试的几点补充

一、控制台的代码格式化

        在浏览器控制台中查看代码时，可以对压缩的代码进行格式化，让其看起来更加美观，更适合阅读。但有时候，这个格式化功能也会导致报错，比如：文件中的“1 .toString”，经过格式化后变成了“1.toString”，而后者存在语法错误。

        在用“点”访问整数的属性或方法时，因为它和小数点存在冲突，为了规避歧义，需要写成以下形式：

1 .toString // 数字和点之间加空格
1..toString // 第一个点是小数点，第二个是操作符
(1).toString

二、反插件&反调试

        使用油猴脚本有时会遇到这种情况：document-start阶段执行的脚本可以正常执行，但document-end阶段的代码似乎没有效果。这时，不要想当然的去检查脚本代码有没有逻辑和语法问题，而应该优先在插件脚本中打上断点看看。

        比如，lanhu网站中对console.log做了修改，导致在document-end阶段的插件脚本不能打印输出。

        我们自己在开发的时候，也可以对一些方法进行hook来反调试。对插件脚本常用的，且又不能直接修改的方法下手效果更佳。比如 document.getElementById，直接对它使用等号赋值无法修改，但可以借助 Object.defineProperty 进行篡改。

Object.defineProperty(document, 'getElementById', {
  enumerable: true,
  configurable: true,
  writable: true,
  value: function () {return document.createElement('span');}
})

        修改之后，别人如果断点调试还可能会发现，所以，实际项目中，我们还应该对篡改相关的代码做不可逆的混淆。

        但有人又要说了，即便是混淆了，别人把方法打印出来也很容易看出端倪（浏览器原始方法打印出来有[native code]字样），发现端倪后，只需要在document-start时，将原始的方法存储下来，再在document-end的代码中使用保存下来的方法就可以了。

        那么，假如我们把 document.getElementById 和 document.getElementByClassName 两个原始方法互换掉呢？隐藏性就可以更进一步了。

        注：当然，通常情况下，网站往往是多人开发维护的，为了便于升级维护，不会hook常用的方法。不过，有心的朋友也许可以开发一个工具库，既不影响开发者，又能在打包项目的时候对浏览器的原生方法进行篡改混淆。

三、调试Vue/React线上网站

        1）之前在《调试上线后的网站（以Vue2为例）》中，在定位Vue实例时，是通过追溯绑定事件的方式；其实，直接打印某个Dom元素也能方便的找到Vue实例（一个元素不行，就多切换几个元素）。

        2）在Vue3网站中，拿到Vue实例后，可以其中找到provides，它通常会包含几个Symbol的键，其中有VueX和VueRouter的相关数据或方法。顺便一提，Vue3中的路由表并没有挂载在options属性中，而是需要调用getRoutes方法来获取。

        3）React项目的调试，不同版本不同环境差别不小，需随机应变。