<link rel="stylesheet">不生效是因为仅stylesheet、icon、preload、modulepreload四类rel值触发加载，写错rel（如"css"）或遗漏则静默跳过；路径需匹配HTML物理位置，相对路径以文件所在目录为基准，Web绝对路径在file://下会错误指向磁盘根。
HTML模板本身不执行加载逻辑，所有外部资源连接都靠标准标签和路径写法生效；用错 rel 值、混用路径类型、忽略加载时机，是 80% 模板资源失效的根源。
为什么 <link rel="stylesheet"> 不生效？
不是所有 rel 值都会触发资源加载。只有 stylesheet、icon、preload、modulepreload 这四类会真正下载并处理资源。写成 rel="css" 或漏掉 rel，浏览器直接跳过——连 404 都不会报。
-
rel="stylesheet"是唯一能加载并应用 CSS 的值，必须配href，type="text/css"可省但建议保留 -
rel="icon"必须同时带type（如image/x-icon）和sizes（如32x32），否则多数浏览器 fallback 到根目录/favicon.ico -
rel="preload"必须加as属性，比如as="script"或as="font"，否则降级为普通<link>，不预加载 - 别在
<link>上写rel="noopener"或rel="noreferrer"：这些只对<a target="_blank">有效，这里纯属被忽略
href 和 src 路径怎么写才不 404？
路径错误是本地开发最常卡住的地方，关键看 HTML 文件物理位置和运行环境：
- 相对路径（
./style.css、../js/main.js）以当前 HTML 文件所在目录为起点，跟浏览器地址栏 URL 无关 - Web 绝对路径（
/css/reset.css）从网站根目录开始解析，适合部署后统一管理，但在file://协议下会指向磁盘根（如C:/css/reset.css），必挂 - 协议相对 URL（
//cdn.example.com/lib.js）自动匹配当前页面协议，但已逐渐被 HTTPS 全站覆盖，实用性下降 - ES 模块脚本（
<script type="module">）的src必须带扩展名（app.mjs），不支持裸路径（src="app"会失败）
JS 脚本放 <head> 还是 <body> 底部？
取决于是否阻塞渲染和依赖 DOM：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 传统脚本（无
type="module"）放在<body>底部最稳妥，避免阻塞 HTML 解析 - 加
defer可放<head>：下载异步，执行等 DOM 解析完、按顺序执行 - 加
async也放<head>：下载异步，下载完立即执行，不保证顺序，适合统计、广告等独立脚本 - ES 模块默认
defer行为，但必须显式声明type="module"，否则当普通脚本处理，可能报错
想复用 HTML 片段（比如 header.html）怎么办？
HTML 标准不支持原生 include，必须选技术路径：
-
<iframe src="header.html">：最简单，但内容是独立文档上下文，样式/脚本不继承主页面，SEO 不友好 -
fetch()+innerHTML：动态注入，共享主页面作用域，但需手动处理脚本执行（<script>标签不会自动运行） - 服务端包含（SSI）或构建工具（如 Webpack 的
html-webpack-plugin）：编译期合并，生成纯静态 HTML，无运行时开销 - 别用已废弃的
<link rel="import">：Chrome 73+ 已移除，所有现代浏览器不支持
最容易被忽略的是路径基准和 rel 语义——它们不报错，只静默失效。调试时优先打开开发者工具的 Network 面板，看请求是否发出、状态码是否 200、MIME 类型是否匹配（比如 CSS 返回 text/html 就是路径错了）。
