必须加 --self-contained true 并指定匹配目标系统的 RID（如 -r win-x64），否则默认依赖框架运行时，缺失 hostfxr.dll 会报错；单文件发布需额外加 --publish-single-file true，二者可叠加但行为不同。
dotnet publish 用什么参数才能打出带运行时的独立包
必须加 --self-contained true，否则默认是依赖框架的（Framework-Dependent Deployment，FDD），目标机器没装对应 .NET 运行时就直接报错 Failed to load library hostfxr.dll。
同时得指定运行时标识符（RID），比如 Windows x64 就是 -r win-x64；Linux ARM64 是 -r linux-arm64。RID 不写或写错，会编译失败或生成不兼容的二进制。
-
dotnet publish -c Release -r win-x64 --self-contained true—— 最小必要命令 - RID 必须和目标系统完全匹配，
win-x64不能跑在win-x86上，也不兼容win-arm64 -
--self-contained false（默认值）会跳过运行时打包，体积小但部署门槛高
单文件发布（Single-file）和独立包（Self-contained）不是一回事
单文件是把所有依赖（包括运行时）打包进一个 EXE 或 ELF 文件，靠 --publish-single-file true 控制；而独立包只是把运行时和依赖放在同一目录下，仍是一堆文件。两者可叠加，但行为差异很大。
启用单文件后，Assembly.GetExecutingAssembly().Location 返回的是内存路径（如 /tmp/.net/MyApp/xxx.dll），不再是原始 EXE 所在目录 —— 这会让基于 Directory.GetCurrentDirectory() 或 AppContext.BaseDirectory 加载配置、资源的代码出问题。
- 单文件 + 独立包：加
--publish-single-file true --self-contained true -r win-x64 - 单文件默认压缩（.NET 6+），启动稍慢但体积小；加
--no-compression可禁用 - 调试符号（.pdb）默认不包含在单文件中，需显式加
--include-symbols-in-single-file
为什么 dotnet publish 后运行报错“找不到 DLL”或“入口点未找到”
常见于混用了不同架构的运行时（比如在 x64 机器上误用了 win-x86 RID），或调用了平台特定的本地库（如 C++/CLI 组件、SQLite 的 native lib）但没一并复制过去。
独立包不会自动包含你 DllImport 的第三方 DLL，也不会帮你处理 NativeAOT 编译外的原生依赖。这些必须手动放进 publish 目录，或通过 CopyToPublishDirectory MSBuild 属性声明。
- 检查错误信息是否含
System.DllNotFoundException或EntryPointNotFoundException - 用
dumpbin /dependents MyApp.exe（Windows）或ldd MyApp（Linux）看缺哪个 native 依赖 - 若项目引用了
Microsoft.Data.Sqlite，得确保对应平台的sqlite3.dll或libsqlite3.so在发布目录里
.NET 6/7/8 单文件启动慢、解压卡顿怎么缓解
单文件首次运行会解压到临时目录（如 /tmp/.net 或 %TEMP%\.net），如果应用体积大（>100MB）、磁盘慢或杀毒软件扫描频繁，就会卡住几秒甚至更久。
这不是 bug，是设计使然。缓解方式有限，且都有代价：要么放弃单文件，要么接受冷启动延迟，要么用 --file-version + --product-version 避免每次重复解压同版本（但仅对相同哈希有效）。
- 加
--no-extract（.NET 7+）可跳过解压，直接从单文件内存加载 —— 但要求所有依赖支持此模式，目前仅限纯托管程序集，含 native 代码的会失败 - 用
AppHost模式（IncludeAppHost=true）可减少启动开销，但不解决解压本身 - 真正想零延迟？回到传统独立目录部署，用脚本打包成 ZIP，用户解压即用
单文件的“方便”是拿启动时间和调试复杂度换来的，尤其在内网低配终端或 CI/CD 自动化场景里，临时目录权限、磁盘空间、防病毒策略都可能突然翻车 —— 这些细节，往往比选对参数还关键。
