背景

  由于IE浏览器停止更新，客户要求我们把系统迁移到谷歌浏览器。因为谷歌浏览器增加了CSP(内容安全策略)校验，我们添加了CSP规则，然后在公司环境测试通过，可以正常访问。但是部署到客户的测试环境中，却因为CSP报错加载不了js，悲剧了。。。
  由于问题一直找不到，公司组织了一个排错小组。因为我参与过项目，所以小组把我也包括在里面。排错没什么技巧，要么是熟练一眼看出来；要么就是把所有可能因素列出来，然后一个个排除，最终确定问题点。

排错过程

  根据报错信息，确定是CSP策略配置问题导致js不加载。那么就有可能是CSP配置错了。但是在我们公司自己的环境配置后，是可以加载js的，页面也能正常访问。这说明配置没有问题。
  我猜想可能是CSP在客户环境可能没生效。因此让客户在浏览器下按下F12,看看响应头的信息内容，果然没有我们配置的CSP信息。再看公司的响应头是有这部分CSP内容的。问题前进一步，是客户的环境丢失了CSP配置。
  我猜测客户在tomcat和浏览器之间使用了某个中间件，这个中间件没有把CSP配置响应给浏览器。经过询问客户，他们是使用了apache服务器进行请求转发的。
  接着验证，让客户把apache关闭，直接访问tomcat，问题没有出现。这就确认了是apache服务器的问题。经检查apache本身配置了csp策略，覆盖了我们应用程序的csp策略。删除apache配置的csp，问题解决。。。

总结

  问题排错，其实就是一个猜想-验证的过程，把可能产生问题现象的环节全列出来，然后一个个验证，排除，直至找到问题。排错过程中特别忌讳想当然认为某个环节一定没问题。往往认为最不可能的点，反而就是问题所在。
  在排错的时候有两点要注意，
一，过于相信某个点没有问题，而问题恰恰就在这里。
二，引起问题的因素没有列全。
  文中的问题就是没有把问题因素列全，花费的了大量时间在配置信息上打转，尝试各种配置，就是解决不了问题，因为配置本来就没错。

当你排除所有的可能性。剩下最后一个的时候，即使再不可思议也是真相