中小型纯前端HTML网站应采用assets/统一资源目录+pages/分离内容页的结构：index.html置于根目录，pages/下存放about.html等页面，assets/css/、assets/js/、assets/images/三层固定，所有资源引用使用如href="assets/css/main.css"的稳定相对路径。
HTML项目目录结构没有唯一“正确答案”，但有明显更少出错、更容易协作和长期维护的组织方式。关键不是层级多深，而是路径语义清晰、资源引用稳定、新增文件时不用反复改相对路径。
静态站点该用哪种基础结构
中小型纯前端 HTML 网站（比如企业官网、作品集、文档页），直接采用 assets/ 统一资源目录 + pages/ 分离内容页的结构最稳妥：
-
index.html放根目录，作为默认入口 -
pages/下只放 HTML 文件，如about.html、contact.html，不嵌套子目录（除非明确需要语义化路径，如pages/blog/post-1.html） -
assets/css/、assets/js/、assets/images/三层固定，避免出现css/main.css和js/lib/jquery.js混用不同层级的混乱 - 所有 HTML 中的资源引用统一用相对路径，例如
<link rel="stylesheet" href="assets/css/main.css">，确保页面无论放在根目录还是pages/下都能正常加载
为什么不要把 JS/CSS 直接扔根目录
看似省事，实则埋下三类问题：
- 当新增一个
pages/about.html时，<script src="main.js">会尝试从pages/main.js加载，404 - 多人协作时，有人加
utils.js，有人加helpers.js，没人敢删“看起来没用”的文件，根目录迅速变成垃圾场 - 构建工具（如 Vite）默认不处理根目录下的非入口文件，未来想加 TypeScript 或 Sass 时得重排路径
用 assets/js/main.js 虽然多打几个字符，但路径含义明确，IDE 自动补全可靠，CI/CD 构建脚本也更容易写死规则。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
什么时候该拆 components/ 目录
不是“项目变大了就拆”，而是当你反复复制粘贴同一段 HTML（比如页头、卡片、表单）超过三次时，才值得引入组件化组织：
- 每个组件单独一个文件夹，如
components/header/，内含header.html、header.css、header.js - 不建议在纯 HTML 里硬编码组件内容；如果不用构建工具，可用
<include>（需服务器支持）或服务端模板（如 PHP 的include）注入 - 若用 FastHTML 或类似框架，直接用函数封装模板，
header_template()比维护一堆 HTML 片段更可控 - 警惕过早抽象：一个只有
<nav><ul><li>...</li></ul></nav>的nav.html，不如直接写在index.html里——抽象成本高于收益
容易被忽略的细节：路径一致性比目录深度更重要
开发者常纠结“要不要在 assets/ 下再建 fonts/”或“images/icons/ 是否多余”，其实真正影响维护效率的是路径是否统一：
- 所有图片都走
assets/images/xxx.png，别一半在images/、一半在assets/img/ - 所有第三方库集中到
assets/js/lib/，不接受js/jquery.min.js这种例外 - 如果用了
src/+dist/构建流程，确保dist/输出结构与开发时引用路径完全一致，否则本地能跑、部署就报 404
目录结构不是用来展示“我懂架构”的，是防止三个月后你自己打开项目时，对着 ../js/../lib/utils.js 这种路径发呆两分钟还找不到文件在哪。
