很多人学 JavaScript 时，会把安全和性能看成“高级专题”，觉得先把功能写出来再说。但真实项目恰恰相反，很多线上事故不是因为不会写交互，而是因为忽略了安全边界和性能成本。页面能显示，不代表安全；交互能完成，不代表体验稳定。浏览器里跑的 JavaScript 同时面对用户输入、外部数据、渲染链路和资源加载，所以安全与性能其实是前端工程最基础的两条红线。
这一篇会把两个经常被割裂的主题放到一起讲：安全防的是“不该发生的事”，性能防的是“本该发生但发生得太差”。它们都要求你从“功能完成”升级到“运行质量”视角。
为什么 XSS 和 CSRF 是前端绕不过去的基础？
XSS 的核心风险在于，恶意脚本被注入并在页面上下文中执行；CSRF 的核心风险在于，用户在已登录状态下被诱导发起了非本人意图的请求。两者方向不同，但都说明一个事实：浏览器不是只运行你“写的代码”，它还不断接收外部输入、响应请求、附带身份信息。
所以安全的第一原则不是“相信当前页面逻辑没问题”，而是永远假设输入可能不可信、请求上下文可能被滥用。很多看起来只是前端展示的小问题，一旦和浏览器执行环境结合，就可能升级成安全漏洞。
为什么前端也必须理解安全，而不能全甩给后端？
因为很多风险正好发生在浏览器这一层。比如把未清洗的富文本直接插入页面、错误地把敏感 token 暴露给脚本上下文、对跨站请求和来源控制缺乏基本判断、在 DOM 操作时不注意内容注入边界，这些都不是后端单独能兜住的。
前后端安全当然需要协同，但前端必须清楚自己控制的边界：哪些内容可以直接渲染，哪些必须转义；哪些状态可以放本地，哪些不能；跨域请求时有哪些限制；页面里出现的第三方脚本意味着什么。
性能为什么不只是“页面快一点”？
性能不是锦上添花，它直接决定用户体验和系统可承受的复杂度。浏览器性能问题常见在几个位置：
- JavaScript 执行时间过长；
- DOM 操作过于频繁；
- 样式和布局计算成本过高；
- 资源加载顺序不合理；
- 高频事件处理没有节制。
很多卡顿问题并不是出在某一行代码有错，而是因为你没有意识到浏览器渲染管线和主线程资源是有限的。只要有一个环节持续占满主线程，点击、滚动、动画和渲染都会受影响。
重排和重绘为什么需要特别关注？
重排通常意味着布局重新计算，重绘意味着视觉重新绘制。两者都可能带来额外开销，尤其是在复杂页面和高频更新场景中。如果你频繁读取布局信息、再立即写入样式、再读再写，就可能造成性能抖动。
项目里更稳的方式通常是：
- 尽量批量更新样式和结构；
- 避免在高频事件里反复触发布局读写；
- 把复杂计算和界面更新分离；
- 利用更合理的动画和渲染策略。
真正要学会的不是“背重排重绘定义”，而是看到某类操作时能立刻意识到它可能影响渲染成本。
节流和防抖为什么经常被滥用？
因为很多人把它们当成性能万能药。实际上，节流和防抖只是在高频事件下控制执行频率的两种策略。它们适合滚动、输入联想、窗口变化等场景，但不是所有卡顿问题都能靠这两个词解决。
用之前你要先想清楚：
- 我真正要解决的是重复触发太多，还是最后一次触发就够？
- 这个交互对即时响应要求高不高？
- 被延后的逻辑是否会影响用户感知和状态一致性？
如果没有这些判断，就很容易把用户交互做得“省性能但体验变差”。
资源加载顺序为什么直接影响首屏体验？
JavaScript 不仅参与业务逻辑，也会影响资源加载和解析时机。脚本体积、加载方式、是否阻塞渲染、代码是否拆分、第三方脚本是否过多，都会影响页面进入可交互状态的速度。前端性能优化并不总是从代码逻辑开始，很多时候是从资源管理和加载策略开始。
这也是为什么现代工程化工具会强调代码拆分、按需加载、懒加载和资源压缩。它们本质上都在帮助你更好地管理首屏成本。
常见误区
这一章最典型的误区包括：
- 认为安全是后端单独负责的；
- 只知道 XSS、CSRF 的名字，却说不清触发路径；
- 页面稍微卡就立刻套节流防抖，而不是先定位瓶颈；
- 忽略 DOM 与布局读写时机，靠经验乱优化；
- 优化只盯着 JavaScript 代码，不关注资源加载顺序和第三方依赖。
和后续章节的关系
后面我们会进入工程化、服务端协作和更深入的安全、性能专题。这一篇更像总览，让你先知道浏览器安全和性能为什么必须从一开始就纳入思考，而不是等出事再补救。
写在最后
真正成熟的 JavaScript 开发，不是把功能堆完，而是在功能之外持续关注运行质量。安全要求你敬畏浏览器执行环境，性能要求你敬畏主线程和渲染成本。把这两条线提前建立起来，后面的项目实践才更稳。下一篇我们开始进入工程化入口。