怎么用文件内容哈希值触发语义版本升级
语义版本（SemVer）本身不规定如何判断“重大变化”，它只定义
MAJOR.MINOR.PATCH的含义。C# 项目里，想让版本号随文件内容实质变更自动调整，必须自己建立「内容变更 → 版本段递增」的映射逻辑，不能依赖
dotnet pack或
MSBuild默认行为。
常见错误是直接比对文件字节或用
File.GetLastWriteTime——这会把格式调整、注释修改、空行增删都当成“重大变化”，违背语义版本初衷。 真正该监控的是**影响二进制兼容性或行为契约的内容**：如 public 类型定义、方法签名、序列化字段名、配置项 key 名称 推荐做法：提取源码 AST 或 IL 元数据，只比对 public API 面向消费者的契约部分（可用
Microsoft.CodeAnalysis或
dotnet-api-docs工具链） 若仅限单个文本文件（如 JSON Schema、OpenAPI spec），可直接计算
SHA256哈希，但需明确约定：哈希变 →
MAJOR升级（因为无法自动判断变更性质）
C# 项目中哪里注入内容哈希校验逻辑
MSBuild 是最自然的切入点，因为构建前就能读取源文件，且能影响
AssemblyVersion和
PackageVersion。别在 CI 脚本里做这事——容易和本地开发脱节，也绕过 IDE 缓存机制。
关键点：必须在
CoreCompile之前运行自定义 target，并通过
$(Version)或
$(PackageVersion)属性透传结果。 在
.csproj里添加
<target name="CalculateContentVersion" beforetargets="CoreCompile"></target>用
<exec command="powershell -Command ... "></exec>调用哈希计算脚本（注意跨平台时改用
dotnet tool封装的 CLI 工具） 把结果写入
<propertygroup><version>1.2.0</version></propertygroup>，后续打包自动继承 避免在
Directory.Build.props中硬编码路径，用
$(MSBuildThisFileDirectory)动态定位被监控文件
为什么不能直接用 Git commit hash 当版本号
Git hash 看似简单，但它和语义版本目标冲突：一次 commit 可能含多个语义无关变更（比如修 typo + 加新 API），而一次语义重大变更又可能跨多个 commit。用户看到
1.2.0+abc123并不知道
abc123是否引入了破坏性改动。
git describe --tags生成的版本（如
v1.2.0-5-gabc123）只反映距最近 tag 的提交数，不反映内容差异程度 若强制用 hash 替代
MAJOR，会导致 NuGet 包管理器无法识别升级关系：
MyLib.1.2.0+abc和
MyLib.1.2.0+def被视为同级，不会提示更新 真正需要的是「确定性哈希 + 显式语义标注」：比如用
SHA256校验核心 contract 文件，再人工或通过 PR 检查清单确认是否需升
MAJOR
最容易被忽略的兼容性陷阱
很多人只盯着 C# 源码，却忘了资源文件、嵌入式 JSON、XAML、甚至
appsettings.json里的键名变更也会破坏下游行为。这些文件一旦被
EmbeddedResource或
Content引入，就必须纳入哈希监控范围。 用
<itemgroup><content include="config/*.json"></content></itemgroup>时，没加
Update属性会导致增量编译跳过内容变更检测 ASP.NET Core 的
appsettings.*.json若被
CopyToOutputDirectory复制，其哈希变化不会触发程序集版本更新——得单独监听输出目录并重写
AssemblyVersionIL 重写工具（如 Fody）生成的代码不在源码中，但会影响 public API；此时必须基于最终输出的 DLL 进行 API 比较，而非源文件
实际落地时，最麻烦的不是算哈希，而是界定「什么算重大变化」——这没法全自动，得靠团队约定 + 机器辅助标记。比如给 PR 加 label：
semver:major，CI 才去跑全量 API diff。
