按 F12 的人比按 Ctrl+U 的人多得多。这俩操作都能看到网站源代码,源代但看到的码查东西完全不是一回事。F12 打开的网站是开发者工具,里面是源代浏览器解析、执行、码查动态修改之后的网站 DOM 树。Ctrl+U 弹出来的源代才是服务器原封不动吐回来的 HTML 文本。很多人把这两者混为一谈,码查结果调试时对着 Elements 面板里的网站代码改了半天,刷新一下全没了——因为那只是源代浏览器内存里的一棵临时树,不是码查源文件。
我最早注意到这个区别,网站是源代帮朋友看他公司官网的一个表单提交问题。他在 Elements 里看到 <input name="user">,码查后端却一直报字段缺失。我让他按 Ctrl+U 看原始 HTML,发现服务器返回的其实是 <input name="username">。浏览器里那个 user 是某段 JavaScript 跑完后改的。他对着被篡改过的现场排查了半天,方向从一开始就偏了。
原始 HTML 长什么样?拿一个最普通的页面举例,服务器返回的代码大概是这样:
就这么几行。你按 Ctrl+U 看到的就是它。但如果你按 F12,会发现 #app 里面塞满了各种 <div>、<span>、<button>。那些全是 main.js 执行后动态生成的。源代码里干干净净,运行时却热闹非凡。这就是现代前端开发的常态——原始 HTML 越来越像一个空壳,真正的结构由 JavaScript 在浏览器里现场搭建。
那查看源代码还有什么用?用处不小。第一,看 SEO 相关的 meta 标签、结构化数据、服务端渲染的内容,必须看原始 HTML。搜索引擎爬虫拿到的就是这一份,不会等你的 JavaScript 跑完。第二,排查服务端模板渲染问题,比如变量没替换、循环写错了,原始输出里一目了然。第三,检查敏感信息泄露——有些粗心的开发者会把 API 密钥、内部路径、注释掉的调试代码留在 HTML 里。Ctrl+U 一按,全露馅。
“源代码”这个词本身就有歧义。对浏览器来说,DOM 才是它理解的源代码;对服务器来说,那个 .html 文件才是。两拨人说的根本不是同一件事。
我自己的习惯是:先 Ctrl+U 看服务端给了什么,再 F12 看浏览器把它变成了什么。两个窗口并排,差异就是 JavaScript 干的好事。这比在 Sources 面板里翻压缩过的 bundle 文件高效得多。当然,如果页面是纯客户端渲染,Ctrl+U 里基本啥也看不到,那就只能靠 F12 和 Network 面板了。工具没有优劣,关键是你得清楚自己正在看的是哪一层。
下次有人跟你说“我看了网站源代码”,多问一句:你看的是哪个源代码?Ctrl+U 还是 F12?答案不同,讨论的起点就不同。
```