内容摘要：web开发入门时，大部分人第一眼看到的是HTML标签，第二眼是CSS样式，然后就被JavaScript折磨得死去活来。但真正的web基础，比这三个东西要更底层一点。 浏览器拿到一个URL，第一步是DN

web开发入门时，础知大部分人第一眼看到的识点是HTML标签，第二眼是整理CSS样式，然后就被JavaScript折磨得死去活来。础知但真正的识点web基础，比这三个东西要更底层一点。整理

浏览器拿到一个URL，础知第一步是识点DNS解析。这个环节经常被忽略，整理但它决定了你输入网址后是础知秒开还是转圈三秒。DNS就是识点把域名翻译成IP地址的电话簿，它本身是整理个分层结构，从根服务器到顶级域再到权威服务器，础知每一层都有缓存。识点我见过不少性能问题，整理最后查出来是DNS解析时间占了总耗时的一半——这时候你优化再多前端代码都没用。

接着是TCP连接。HTTP/1.1时代，每个请求都要建立一次TCP连接，所以有了Keep-Alive来复用连接。HTTP/2引入了多路复用，一个连接可以同时传输多个请求。到了HTTP/3，干脆把TCP换成了UDP-based的QUIC协议，目的是减少握手延迟。这些协议演进背后，核心就一个字：快。但快是有代价的——HTTP/2的头压缩算法HPACK出了几个漏洞，QUIC的拥塞控制还在持续优化中。

请求到了服务器，后端处理完返回响应。响应里有个状态码，200代表成功，301是永久重定向，404是资源不存在，500是服务器内部错误。状态码的语义设计其实挺讲究的——比如302和303的区别，一个说“临时挪走了”，一个说“用GET方法重新请求”。但实际开发中，很多人把302和303混着用，导致一些缓存代理服务器行为异常。

浏览器拿到HTML后开始解析，构建DOM树。这个过程是边下载边解析的，所以script标签放在body底部是有道理的——脚本会阻塞DOM解析。CSS则不同，它会阻塞渲染，但不会阻塞DOM解析。有意思的是，浏览器还有个预加载扫描器，会在解析HTML的同时提前发现资源并下载，这就是为什么有时候你看到页面图片已经加载完了，但DOMContentLoaded事件还没触发。

渲染流程里还有个容易被忽略的点：回流和重绘。改变元素的几何属性（宽度、高度、位置）会触发回流，浏览器必须重新计算布局。改变颜色、背景这种不影响布局的属性，只触发重绘。回流是性能杀手，因为它会影响整个渲染树的布局计算。实际开发中，我见过有人频繁用JavaScript读取offsetWidth这类属性，结果强制浏览器同步执行布局，导致页面卡顿——正确做法是批量读取或者用requestAnimationFrame。

存储这块，cookie、localStorage、sessionStorage各有各的坑。cookie会随每个请求发送到服务器，所以不适合存大数据，4KB的限制摆在那。localStorage是5MB左右，但它是同步API，在主线程上读写大量数据会阻塞渲染。sessionStorage只在当前标签页有效，标签页关了数据就没了。IndexedDB是个异步的NoSQL数据库，功能强大但API设计得反人类——不过现在有包装库，用起来没那么痛苦了。

安全方面，XSS和CSRF是两大经典问题。XSS的核心是没对用户输入做转义，让恶意脚本注入了页面。CSRF则是利用浏览器自动携带cookie的机制，诱导用户发起非预期请求。防御手段也直接：XSS用CSP（内容安全策略）限制脚本来源，CSRF用CSRF Token验证请求来源。但很多人不知道，CSP的strict-dynamic模式能有效防止第三方脚本注入，代价是需要自己管理所有脚本的信任来源。

最后说说web存储和缓存策略。HTTP缓存有强缓存和协商缓存之分，强缓存用Expires或Cache-Control，协商缓存用Last-Modified或ETag。实际项目中，静态资源一般用强缓存配合文件名hash，HTML文档用协商缓存。有个容易踩的坑：如果你给HTML也设置了强缓存，用户刷新页面后拿到的还是旧版本，改代码也没用——必须清缓存才能看到更新。

这些知识点单个看都不难，但它们组合在一起，才构成了web运行的真实逻辑。遇到问题的时候，顺着请求链路一层层排查，比瞎猜要高效得多。