ASP.NET Core 中通过 asp-append-version="true" 可自动为本地 CSS 文件 URL 添加基于内容的 SHA256 哈希版本号，确保缓存更新；仅对 ~/ 或 / 开头的相对路径生效，绝对 URL 被跳过，且每个文件独立计算哈希。
直接结论：部署时注入 CSS 版本号，核心是让 URL 变化且可预测，不是改文件名；手动加 ?v= 最快但易漏，构建工具哈希最稳，ASP.NET Core 的 asp-append-version="true" 是特例级自动化方案。
用构建工具生成内容哈希（推荐）
Webpack、Vite、Rollup 等现代构建工具能基于 CSS 文件内容计算哈希值，并重命名输出文件（如 main.8a3f2d.css），再自动更新 HTML 中的 <link> 引用。这种方式精准、可复现、无需人工干预。
- Webpack 配置关键项：
output.filename: '[name].[contenthash:8].css'，配合HtmlWebpackPlugin自动注入 - Vite 中启用
build.rollupOptions.output.entryFileNames并设为[name].[hash].css即可生效 - 哈希值随内容变，不变则 URL 不变，浏览器缓存复用率最高
- ⚠️ 注意：若 CSS 被拆成多个 chunk（如按路由分块），每个 chunk 独立哈希，不要指望所有 CSS 共享一个版本号
在 HTML 模板中动态插入时间戳或版本号
适用于无构建流程或轻量项目（如 PHP、JSP、ASP.NET Web Forms），靠服务端运行时读取文件元信息生成参数。
- PHP 示例：
<link rel="stylesheet" href="css/app.css?v=<?php echo filemtime('css/app.css'); ?>"> - Node.js（Express）示例：
res.render('index', { cssVersion: Date.now() })，模板中写<link href="style.css?v=<%= cssVersion %>"> - ⚠️ 注意：
filemtime在 CDN 或只读部署环境可能不准；若用 Git 提交哈希（如v=abc123），需确保构建脚本提取并注入该值 - 不建议用纯时间戳（如
v=1716235200），除非每次部署都强制刷新——否则同一版本多次发布会生成不同 URL，浪费缓存
ASP.NET Core 中启用 asp-append-version="true"
这是框架原生支持的零配置方案，但有明确边界：只对本地路径（~/ 或 / 开头）生效，且依赖 IFileProvider 读取文件内容算 SHA256。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
<link rel="stylesheet" asp-href-include="~/css/site.css" asp-append-version="true"> - 通配符也支持：
asp-href-include="~/lib/bootstrap/css/*.min.css"→ 每个匹配文件单独哈希、独立<link> - ⚠️ 绝对 URL（
https://cdn.example.com/style.css）或协议相对路径（//cdn...）完全跳过处理，不会加任何参数 - 调试时发现版本号没变？先确认文件内容是否真被修改 —— 它不看修改时间，只看字节内容
别踩这些坑
版本号注入看似简单，实际失效常因基础设施链路断裂：
- CDN 默认忽略查询参数（
?v=xxx）做缓存键 → 必须在 CDN 后台开启「缓存键包含查询字符串」 - HTTP 响应头设了
Cache-Control: immutable→ 浏览器彻底无视 URL 变化，强制沿用旧缓存 - HTML 中写错路径（如
css/general.css?v=1.1但实际文件在static/css/）→ 404，样式根本加载失败 - Webpack 已输出
app.a1b2c3.css，你还手动加?v=1.1→ 冗余且干扰长效缓存策略
真正要盯住的不是“怎么加”，而是“加完之后，从 HTML 渲染 → 请求发出 → CDN 转发 → 服务器响应 → 浏览器缓存判定”整条链路里，哪一环把版本标识吃掉了。
