去年帮朋友看一个企业站，网站首页轮播图死活不切换。脚本打开控制台，代码一行红字：Uncaught TypeError: Cannot read property 'style' of null。网站查了半天，脚本发现是代码脚本里写死了 document.getElementById('banner')，而模板改版后那个 id 早换成了 slider-wrap。网站改一个字符，脚本问题消失。代码这种事我碰过太多次——网站脚本代码往往不是网站写得多高深，而是脚本细节对不上就全盘罢工。

脚本代码在网页里干的代码事，说直白点就三类：操作 DOM、网站发请求、脚本处理数据。代码但真写起来，坑全藏在执行时机上。比如你把 <script> 放在 <head> 里直接 querySelector，浏览器解析到那一行时，下面的按钮压根还没生成，当然报 null。老手会加 defer，或者把脚本挪到 </body> 前面。新手容易忽略这点，然后对着“元素明明存在”的代码怀疑人生。

再举个常见的：表单提交。很多人写 form.onsubmit = function() { ... }，里面做了校验，但不写 return false 或 event.preventDefault()。结果校验弹窗一闪，页面照样刷新，用户填的数据全没了。我见过一个后台系统，登录页每次点提交都闪一下白屏，查到最后就是脚本里少了这一句。加上之后，ajax 请求才正常发出去。

异步请求那块，fetch 和 XMLHttpRequest 的写法差异也常让人翻车。fetch 默认不带 cookie，跨域时得手动加 credentials: 'include'。有次调一个第三方登录接口，前端一直拿不到 session，后端日志显示请求根本没带凭证。改成 fetch(url, { credentials: 'same-origin' }) 才通。这种细节文档里写了，但赶进度时没人细看。

还有一类脚本代码是第三方统计或广告。它们通常动态创建 <script> 标签，插入到页面里。问题在于，如果页面用了 CSP（内容安全策略），这些外链脚本会被直接拦掉。我帮一个客户排查过：百度统计代码明明加了，后台就是没数据。F12 一看，控制台报 Refused to load the script，原因是他们的运维在 nginx 里加了 script-src 'self'。把统计域名加进白名单，数据立马有了。

写脚本代码，我自己的习惯是：先确认 DOM 就绪，再绑事件；所有网络请求都加错误回调；能用 const 就不用 var。另外，别迷信压缩后的代码。有次线上出 bug，我对着 minify 后的 a.b.c() 看了半小时，最后在源码里发现是变量名被压缩后跟全局变量冲突了。后来那个项目我坚持保留 source map，排查效率高很多。

脚本代码不是写完就完事。浏览器版本、扩展插件、甚至用户网络环境都会影响执行。一个在 Chrome 里跑得好好的轮播，到了 Safari 可能因为 passive event listener 的默认行为差异变得卡顿。所以我现在写完关键脚本，至少在三类浏览器里过一遍。别等用户反馈“按钮点不动”才去查，那时候你可能连问题复现都做不到。

说到底，网站脚本代码的可靠性，不取决于你用了多新的框架，而在于你有没有把那些“理所当然”的地方挨个验证一遍。一个 id 写错、一个事件没阻止默认行为、一个跨域凭证没带——任何一个都能让整个功能归零。写的时候多问一句“如果这里拿不到元素会怎样”，能省掉后面很多通宵。

(责任编辑：百科)