现象描述
当我们刚开始学习 HTML 时，最直观的操作就是在文件夹中直接双击 index.html。这时浏览器地址栏显示的是：
file:///C:/Users/YourName/Project/index.html
虽然页面能打开，但经常遇到莫名其妙的 Bug：
- ❌ 图片显示不出来（尤其是使用了
/开头的绝对路径时）。 - ❌ AJAX 请求直接报错（CORS 错误）。
- ❌ ES6 模块 (
import/export) 无法运行。
而当我们使用 VS Code 的 Live Server 插件，或者前端框架的 npm run dev 后，浏览器自动弹出的地址是：
http://127.0.0.1:5500/index.html
神奇的是，这时候一切都正常了。这背后的根本原因，在于 协议 的不同。
深度解析：file:// 协议 (本地文件模式)
当你双击文件时，浏览器使用的是 file:// 协议。在这个模式下，浏览器把你当作一个文件查看器，而不是一个网页浏览器。为了保护你的电脑安全，浏览器实施了极其严格的“沙箱限制”。
限制一：路径解析逻辑不同 (图片为何加载失败？)
这是新手最容易踩的坑。如果你的代码写的是绝对路径：
<img src="/logo.png" />- 在 file:// 模式下： 浏览器看到的“根”是你电脑的文件系统根目录（Windows 的 C 盘）。浏览器会尝试去访问：
file:///C:/logo.png。 - 结果： 你的 C 盘根目录下显然没有这张图，所以图片加载失败。
限制二：安全策略不允许网络请求
- 原因： 浏览器的同源策略。
- 现象： 浏览器禁止 JS 通过
fetch或XMLHttpRequest去读取本地文件。 - 为什么： 试想一下，如果随便下载一个网页保存到本地，双击打开后，它就能读取你硬盘里的
C:/Passwords.txt并发送给黑客，那太可怕了。所以浏览器直接禁用了这种能力。
限制三：现代模块化无法使用
- 如果你使用了
<script type="module">(ES Modules)，在file://下会直接报错。因为浏览器认为让一个本地文件去“加载”另一个本地脚本是不安全的。
深度解析：http:// 协议 (Live Server 模式)
当你启动 Live Server 时，你实际上是在本地电脑上搭建了一个小型的 Web 服务器。浏览器通过 http:// 协议与这个服务器通信，这才是标准的“网页浏览”环境。
优势一：正确的“根目录”映射
- 原理： Live Server 会把你当前的项目文件夹，映射为服务器的网站根目录 (Web Root)。
- 结果： 当你请求
<img src="/logo.png">时，浏览器向服务器请求“网站根目录下的 logo.png”。服务器会去你的项目文件夹里找logo.png并返回。 - 结论： 图片成功加载。
优势二：正常的网络权限
- 在
http://环境下，浏览器认为这是一个正常的网站。只要遵守同源策略，你的fetch请求、import模块化语法都可以正常工作。这完全模拟了代码上线后的真实运行环境。
总结对比表
| 特性 | file:// (双击打开) | http:// (Live Server) |
|---|---|---|
| 根目录 (/) 指向 | 电脑磁盘根目录 (如 C:) | 你的项目文件夹 |
| AJAX / Fetch | 被浏览器拦截 (CORS) | 正常工作 |
| ES Modules | 无法加载 | 正常加载 |
| 适用场景 | 仅用于查看纯文本/简单 Demo | 必须用于正式开发 |
思考：为什么要有这种区分？
这并不是浏览器的 Bug，而是有意为之的安全特性。
file:// 协议的设计初衷是让你查看本地文件（比如打开一个 PDF，看一张本地照片），而不是让你运行一个复杂的 Web 应用。一旦涉及到资源引用、数据交互或模块化，我们就必须建立一个符合 Web 标准看齐的服务器环境（即 http://），这不仅是为了功能正常，更是为了模拟真实的用户访问场景。