404错误主因是生成的HTML文件路径与服务器DocumentRoot、链接目标未对齐。需确认文件是否真置于服务器根目录（如./public/），检查生成路径有无遗漏子目录、Windows反斜杠问题、HTML内href/src是否为正确相对或根绝对路径，验证index.html存在且非空，并用curl测试基础可访问性。
批量生成 HTML 后访问报 404，问题几乎总出在路径没对齐——不是代码逻辑错，而是生成时的文件位置、链接目标、服务器根目录三者之间没咬合上。
生成的 HTML 文件是否真被放到了 Web 服务器能访问的路径下
本地双击打开 file:/// 路径不会触发 404，但浏览器会因 CORS 拒绝加载 JS/CSS；而真正报 404，说明你已用 Web 服务器（如 python -m http.server、Live Server、Nginx）访问，但服务器找不到该文件。
- 确认生成脚本输出的 HTML 文件，实际落盘位置是否在服务器的 DocumentRoot 目录内（例如
./public/index.html，而你的 Python 服务启动在./src目录下，那就注定 404） - 检查生成路径是否含意外前缀，比如脚本写了
os.path.join("dist", "pages", "article-1.html")，但你却用http://localhost/article-1.html访问——漏了pages/这一层 - Windows 用户特别注意：生成脚本若用
\拼路径，又没做os.path.normpath处理，可能导致路径变成distpagesindex.html，而 Web 服务器只认/分隔符，某些静态服务会静默忽略
HTML 内部的 href/src 链接是否仍指向旧路径或错误相对路径
批量生成时若直接复制模板或拼接字符串，容易把 ./css/main.css 写死成 css/main.css，或误把 ../images/logo.png 算错层级。这类链接在开发环境可能碰巧能加载，一部署就 404。
- 统一用以站点根目录为基准的绝对路径（
/css/main.css），避免相对路径计算偏差 - 如果必须用相对路径，确保所有生成的 HTML 文件处于同一级目录，且模板中路径计算基于该层级（例如全部放在
dist/posts/下，则../../assets/js/app.js才合理） - 用
BeautifulSoup或正则批量重写生成后 HTML 中的src和href属性值，补全或修正路径，比手改更可靠
生成脚本是否覆盖了关键配置文件或破坏了路由入口
有些静态站点生成器（如 Hugo、Jekyll）依赖 _config.yml 或 index.html 作为默认入口；批量生成若清空输出目录后未重建 index.html，或把 404.html 错误覆盖成空文件，服务器就会直接返回 404（连错误页都拿不到）。
立即学习“前端免费学习笔记（深入）”；
- 检查输出目录是否存在
index.html，且内容非空——哪怕只是<h1>OK</h1> - 确认没有脚本逻辑误删
.nojekyll、CNAME或_redirects这类影响托管平台（GitHub Pages、Netlify）路由的元文件 - 若生成过程涉及模板渲染（如 Jinja2），留意
{% include %}或{% extends %}引用的路径是否在输出阶段失效（例如引用了templates/base.html，但生成时没把该文件也拷进输出目录）
服务器是否识别新生成的 HTML 文件扩展名和 MIME 类型
极少数情况：生成的文件扩展名看似是 .html，实则是 .html.txt（Windows 隐藏扩展名导致）；或者服务器配置未将 .htm 映射为 text/html，返回 404 而非 403/500。
- 用
ls -la dist/（macOS/Linux）或dir /a dist（Windows）确认真实文件名，去掉隐藏扩展名 - 检查服务器日志（如 Nginx 的
error.log），搜索 “open() failed” 或 “No such file or directory”，它会明确告诉你服务器想找哪个路径 - 临时用
curl -I http://localhost/generated.html查看响应头，若返回Content-Type: application/octet-stream，说明服务器没识别类型，需补 MIME 配置
最常被跳过的一步：生成后不验证单个文件能否被服务器直接 GET 到，就急着测链接。先用 curl http://localhost/index.html 确认基础可访问性，再查内部资源——顺序错了，排查成本翻倍。
