用 dotnet pack 打包 SDK 风格类库需指定 --configuration Release，且 .csproj 中必须声明 PackageId 和 Version；发布前须用 nuget.exe push 配合有效 API Key，并本地验证包结构与引用兼容性。
用 dotnet pack 打包类库最直接
只要项目是 SDK 风格（.csproj 文件里有
dotnet pack --configuration Release就会在
bin/Release 下生成 .nupkg 文件。注意别漏掉 --configuration Release——Debug 模式打包可能含调试符号、版本号带 -dev 后缀，上传到 NuGet.org 会被拒。
常见错误：项目没设 Unnamed.1.0.0.nupkg。必须在 .csproj 里显式写：
MyAwesomeLib 1.0.0 YourName A short description
nuget.exe push 发布到 nuget.org
发布前先去 nuget.org 创建 API Key（只显示一次，务必复制保存）。然后执行：
nuget.exe push MyAwesomeLib.1.0.0.nupkg -Source https://api.nuget.org/v3/index.json -ApiKey YOUR_API_KEY_HERE如果提示
nuget.exe 找不到，就去 下载最新版 并加到 PATH，或者用完整路径调用。
容易踩的坑：
- API Key 权限范围要选 “Push new packages”（不是 “All packages”）
- 包名已存在且你不是所有者？会报错
403 Forbidden - 版本号重复？报错
409 Conflict，得升版再推
用 Directory.Build.props 统一管理多项目元数据
如果你维护多个类库，每个都手写 PackageId、Description 容易不一致。可以在解决方案根目录建 Directory.Build.props，内容如下：
所有子项目的https://github.com/you/repo https://github.com/you/repo MIT false
.csproj 就能自动继承这些设置，不用每处重复写。
注意：IncludeSymbols 默认为 true 时会生成 .snupkg，但 nuget.org 要求它和 .nupkg 版本严格一致；若不打算提供源码调试支持，显式关掉更省事。
本地测试包是否可用，别跳过这步
上传前，先在本地验证包结构和引用是否正常：
- 用
nuget.exe install MyAwesomeLib.1.0.0.nupkg -OutputDirectory ./test解压看看lib/目录下有没有对应框架的 dll（比如net6.0/或netstandard2.0/） - 新建一个测试项目，执行
dotnet add package MyAwesomeLib --source ./test，看能否成功解析并编译通过 - 检查
.nuspec内容（用nuget.exe spec生成模板对比）：
TargetFrameworks 和 PackageReference 的兼容性没对齐，本地测一遍能避开 80% 的尴尬。
真正麻烦的是跨平台目标框架（比如同时支持 net6.0 和 netstandard2.0）+ 带原生依赖的场景，这时候 lib/ 下目录结构、runtimes/ 分组、.targets 文件都要手动校验——别指望 dotnet pack 全替你兜底。
