说的是我对 google chrome 在技术方面的过度信任。
最近在学习 react + typescript 的组合。本想着我有多年的 react-native 开发和浏览器前端调试的经验，跟着教程一步步走会很顺利，没想到第一步就栽了。
学习新东西第一步都是搭建开发环境嘛，开发环境建成的指标之一就是可以下断点单步调试。
用 typescript 写 javascript 有一个 sourcemap 源码映射问题，就像写 C++ 程序调试时需要有源代码和实际执行的汇编代码的位置对应关系信息，这里设置不好很容易导致断点加不上。chrome 的问题是在 react 程序第一次编译后下断点没问题，但在不重启 react 服务器端的情况下修改代码编译后用 react 的热更新功能刷新页面后，在 chrome 源码页面里加断点就失效了。
我在源码里加入 debugger 命令试了试，chrome 执行到那里会停下来，所以断点功能本身没坏，他只是不认我在浏览器的调试器里实时加上的断点。
搜了一下，这个问题是有官方 issue 的。看评论这似乎是 chrome 的 sourcemap 功能的 bug，最简单稳定的对策是调试时换用 firefox 。
我从 firefox 换到 chrome 有差不多 10 年了。这期间一直知道他们对浏览器标准的实现非常积极，但因为已经习惯了 chrome 和相信 google 的技术力，所以一直没有再用过 firefox 。
现在看来，我对 chrome 的信任是有些盲目了。其实在 react-native 的开发中我就时不时遇到在 chrome 的调试器里取不到特定 scope 里的变量等问题，但出于对 google 的信任，我一直觉得是 facebook 做的不好，对 chrome 竟然从来没有怀疑过。
盲信除了懒惰，也有无知的原因。比如以前我从来不会怀疑 OS，不会怀疑编译器，不会怀疑 IDE，有错一定是我的错。参加工作以后，我遇到过 android OS 的坑，遇到过 gcc 的坑，遇到过 visual studio 的坑。在世界观被他们一次次重铸后，我学会用了批判性的眼光看技术。这次 chrome 的坑没看出来有我对浏览器领域的了解太匮乏的关系，我甚至没有能力定位到这个 bug，即使 chromium 是开源的！
我太菜了，这不行。
立一个 flag， 总有一天我要亲手定位到这个 sourcemap 断点无效的 bug 在代码中的位置。（反正说大话我最擅长了- -）
