网页源码解析

按F12，网页网页的源码底裤就露出来了。我最早意识到这件事，解析是网页几年前想扒一张背景图——右键另存为，存下来的源码是个空白占位符。打开开发者工具，解析在Elements面板里翻了半天，网页才发现真正的源码图片地址藏在CSS的background-image里。那一刻我明白了：浏览器看到的解析和你能直接拿到的，是网页两回事。

网页源码本质上就是源码浏览器收到的那堆文本。服务器把HTML、解析CSS、网页JavaScript打包扔过来，源码浏览器负责把它渲染成你看到的解析页面。右键“查看网页源代码”拿到的是服务器原始响应，而F12里Elements面板显示的，是经过JavaScript执行、DOM动态修改之后的实时结构。这两个东西经常长得完全不一样。很多前端框架（React、Vue）的页面，源码里可能只有一个空的<div id="app"></div>，所有内容都是JS跑完之后塞进去的。

解析源码这件事，拆开来看就三层。

第一层是HTML结构。标签嵌套关系决定了DOM树的形状。<div>套<div>套<div>，套到第五层的时候你就该想想是不是该重构了。我见过一个电商详情页，光是商品标题就嵌了七层div，没有任何语义。这种结构对写爬虫的人来说是噩梦——你没法用稳定的选择器定位元素，class名还带着哈希后缀，今天叫.title_a3f2b，明天部署一次就变成.title_7c1d9。

第二层是CSS。样式规则决定了每个盒子长什么样、在哪儿。解析CSS比解析HTML麻烦，因为层叠和继承意味着你得追踪优先级。一个元素最终生效的样式，可能来自外部样式表、内联<style>块、行内style属性，还有浏览器默认样式。Chrome的Computed面板会告诉你最终值，但不会告诉你这个值是从哪条规则来的——你得在Styles面板里一条条看，被划掉的就是没生效的。

第三层是JavaScript。这是最动态的部分。JS能改DOM、改样式、发请求、监听事件。你看到的页面交互——下拉加载、点击弹窗、表单校验——全是JS在跑。解析JS源码，重点不是读懂每一行，而是搞清楚它绑定了哪些事件、发了哪些XHR/fetch请求、操作了哪些DOM节点。Network面板比Sources面板更实用，因为你能直接看到数据从哪来、长什么样。

有个细节挺有意思：浏览器解析HTML是从上到下的，遇到<script>标签会暂停解析，先去执行脚本（除非加了async或defer）。这意味着如果你把<script>放在<head>里，页面会白屏等到脚本下载执行完。所以性能优化的一条老规矩是把脚本放<body>末尾。现在有了type="module"和defer，情况好一些，但原理没变。

实际工作中，解析源码最常见的场景就是写爬虫和做自动化测试。爬虫要提取数据，自动化测试要定位元素点击输入。两者都依赖对DOM结构的准确理解。我的习惯是：先用F12找到目标元素，右键Copy selector，拿到一个CSS选择器，然后在控制台用document.querySelector()验证一下能不能选中。能选中，再写进代码。选不中，就往上找稳定的父节点，一层层缩小范围。

源码解析不是读代码，是读结构。你不需要理解每一行JS在干什么，但你需要知道数据在哪个节点、样式由哪条规则控制、交互绑在哪个元素上。这三个问题回答了，网页对你来说就是透明的。