github actions 是 c# 项目 ci/cd 最省事选择，但需显式安装 .net sdk、正确配置测试适配器、安全注入密钥、区分 runtime 与 sdk、独立执行 restore 并验证发布环境。
GitHub Actions 是 C# 项目做 CI/CD 最省事、最不容易翻车的选择——不用自建服务器，不绑 Azure 订阅，只要仓库公开或私有权限配对，dotnet build 就能跑起来。但多数失败不是因为语法错，而是环境没对齐、测试没适配、发布密钥裸奔。
dotnet build 报 “command not found” 怎么办
这不是你写错了命令，是 runner 根本没装 .NET SDK。Ubuntu 和 Windows runner 默认都不带 SDK，必须显式安装。
-
runs-on必须明确写成ubuntu-latest或windows-latest，不能只写ubuntu - 紧接
checkout后，必须加actions/setup-dotnet@v4步骤 -
dotnet-version要和.csproj里<targetframework></targetframework>完全匹配，比如net8.0就得填8.x，填8.0.x会静默失败 - 如果项目含
global.json，dotnet-version还得和它里面的sdk.version一致，否则dotnet build会用错版本
dotnet test 找不到测试或直接崩溃
常见现象是控制台输出 No test is available 或抛 PlatformNotSupportedException，根本原因不是代码问题，而是运行时环境或包缺失。
- 测试项目必须引用
Microsoft.NET.Test.Sdk，否则dotnet test无法加载测试适配器 - 用 xUnit 的话，还得加
xunit.runner.visualstudio（.NET Framework）或xunit.runner.console（.NET Core+） - 别在
ubuntu-latest上跑调用Registry、WMI或WindowsPrincipal的测试，这类 API 在 Linux 下直接炸 - 本地能过 CI 过不了？加参数
--no-build --verbosity normal，能快速区分是编译失败、发现失败，还是执行崩溃
dotnet publish 后怎么安全推到云环境
dotnet publish -c Release -o ./publish 这条命令本身几乎不会出错，真正卡住的是“发到哪”和“怎么鉴权”。硬编码密钥、用错 Action、漏掉登录步骤，三者占发布失败的 90%。
- 推 Docker 镜像：先用
docker/login-action登录镜像仓库（阿里云、腾讯云、GHCR），再用docker/build-push-action构建并 push - 发到 Azure Web App：用
azure/webapps-deploy@v2，但app-name和package路径必须和实际部署结构对上，./publish是常见目标路径 - 微信云托管：必须用官方 CLI 工具，且依赖两个 Secret：
WXCLOUD_APPID和WXCLOUD_CLI_SECRET，缺一不可 - 所有密钥都必须存在 GitHub Secrets 里，YAML 中用
${{ secrets.XXX }}引用；绝不能出现在env:块里或命令行拼接中
Release 模式下发布仍启动失败？检查这三点
本地双击 MyApp.exe 能跑，CI 发布后扔到服务器就报“找不到 DLL”或“无法加载 hostpolicy.dll”，大概率是 runtime、依赖、配置三者之一没对齐。
- 确认目标服务器装的是对应版本的
.NET Runtime（不是 SDK），比如net8.0项目就得装.NET 8 Runtime，用dotnet --list-runtimes验证 - 检查
dotnet publish是否用了--self-contained false（默认值），若设为true，体积大但可脱离目标机 runtime 环境 -
appsettings.json里的连接字符串、第三方 API 地址等，不能写死开发值；建议用ASPNETCORE_ENVIRONMENT=Production+appsettings.Production.json分离配置
最常被忽略的一点：CI 流水线里没做 dotnet restore 显式还原，靠 build 自动触发看似能过，但一旦涉及私有 NuGet 源或 Directory.Packages.props，就会在 publish 阶段突然失败——还原必须独立成 step，且需提前配置源凭据。
