Blazor组件迁移目录后服务器环境下Scoped CSS作用域不匹配问题

遇到这种本地运行正常，但服务器（Azure Web App）上Scoped CSS作用域哈希不匹配的情况，大概率是部署残留的旧文件或者编译缓存搞的鬼，给你几个实用的解决方向：

• 彻底清理服务器与本地的旧编译产物

  • 先在Azure Web App的控制台里，找到wwwroot目录下的{你的App名称}.styles.css文件，手动删除它，然后重新部署最新的代码。
  • 本地发布前，务必清空bin/Release/netX/publish（X对应你的.NET版本）目录下的所有文件，再重新生成发布包，避免旧的哈希文件混进新部署包。

• 强制触发Scoped CSS哈希重新生成

  • 随便修改一下Page.razor.css的内容（比如加个空行再删掉），这样能让Blazor重新计算该组件的作用域哈希，不会复用旧的缓存值。
  • 检查你的项目文件（.csproj），确保没有添加<DisableScopedCssBundling>true</DisableScopedCssBundling>这类禁用Scoped CSS打包的配置，要是有就删掉它。

• 优化部署流程避免残留文件

  • 如果用自动部署工具（比如Azure DevOps、GitHub Actions），记得开启“清理目标目录”的选项：比如Azure DevOps的Azure Web App Deploy任务里，勾选Remove additional files at destination，这样部署时会删掉服务器上不属于当前发布包的旧文件，从根源避免冲突。
  • 手动上传的话，一定要上传完整的最新发布包，别只传修改过的几个文件，很容易遗漏依赖的哈希文件。

• 再次确认样式引用的正确性

  • 再核对一遍App.razor里的样式引用：<link href="{你的项目程序集名称}.styles.css" rel="stylesheet" />，有时候目录迁移后如果调整过项目配置，程序集名称可能变了，导致引用的样式文件不对，自然匹配不上哈希。

如果以上方法都没解决，可以试试在本地模拟发布环境运行：用dotnet publish生成发布包，然后用dotnet {你的项目名}.dll启动，看看本地发布版会不会出同样的问题。如果本地正常，那基本就是Azure服务器的缓存问题，重启一下Web App服务就能搞定。

备注：内容来源于stack exchange，提问作者Schlafhase