用 dotnet pack 生成 .nupkg 文件的核心是基于 SDK 风格项目直接打包，需显式指定 --configuration Release 和输出路径；元数据应写在 .csproj 中，避免手动维护 .nuspec；多框架支持通过 <TargetFrameworks> 声明；推送时须用 nuget.org 的 scoped token 并指定 v3 源；发布后需等待索引完成并清除本地缓存方可正常使用。
怎么用 dotnet pack 生成 .nupkg 文件
核心是把项目编译输出和 .nuspec（或项目文件内声明）打包成标准 NuGet 包。直接运行 dotnet pack 就行，但默认行为容易踩坑。
-
dotnet pack默认只打包Release配置，如果项目没切到 Release，会生成空包或报错 - 推荐显式指定：
dotnet pack --configuration Release --output ./nupkgs - 若项目是 SDK 风格（
<Project Sdk="Microsoft.NET.Sdk">），无需单独写.nuspec，元数据直接写在.csproj里更可靠，比如：<PackageId>MyLib</PackageId>、<Version>1.0.0</Version>、<Authors>Me</Authors> - 别手动改
.nuspec后再用nuget pack—— 它不识别 SDK 风格项目，会漏引用、丢 XML 文档，且版本号容易和.csproj不一致
为什么 dotnet nuget push 总提示 403 或 “API key is invalid”
不是密码错了，而是认证方式不对。nuget.org 现在强制用 token，不是账户密码，也不是旧的 API key。
- 去 https://www.php.cn/link/23b6ccd661757295a41abd6a7ee3ac2d 创建一个 scoped token（建议 scope 限定为
Push+ 具体Package ID，别用*） - 用
dotnet nuget push时必须加--api-key和--source：dotnet nuget push ./nupkgs/MyLib.1.0.0.nupkg --api-key xxxxxx --source https://api.nuget.org/v3/index.json - 别用
nuget.exe push—— 它默认走 v2 源，而 nuget.org 的 v2 已停用，会返回 403 或超时 - 如果本地有
NUGET_API_KEY环境变量，dotnet nuget push不会自动读取，必须显式传参
如何让包支持多 Target Framework（如 net6.0 + netstandard2.0）
不是靠多个 .csproj，而是在单个项目里声明多个目标框架，否则用户安装时可能找不到匹配项。
- 在
.csproj中写：<TargetFrameworks>net6.0;netstandard2.0</TargetFrameworks>（注意是复数TargetFrameworks） - 条件编译代码用
#if NET6_0或#if NETSTANDARD2_0，别用硬编码路径或运行时判断 -
dotnet pack会自动为每个 TF 生成对应程序集，并放进lib/<tf>/目录下；不手动干预.nuspec的<files>段 - 如果只写
<TargetFramework>（单数），即使加了<PackageTargetFallback>，也无法真正生成多框架包，下游项目引用时会 fallback 失败或警告
发布后别人装不上，或者 IDE 不提示更新怎么办
常见原因是包没进索引队列，或本地缓存太旧，不是代码或版本问题。
- nuget.org 接收包后需要几分钟到十几分钟才完成索引（尤其新包首次发布），期间
dotnet add package可能提示“找不到”，等一等再试 - 本地执行
dotnet nuget locals all --clear清掉缓存，再重试安装 - 确认包名大小写完全一致 —— NuGet 包名区分大小写，
MyLib和mylib是两个不同包 - 如果用了预发布版本（如
1.0.0-alpha），dotnet add package默认不拉预发布包，得加--prerelease参数
最常被忽略的是：包上传成功不等于立刻可用，索引延迟和客户端缓存是真实存在的物理时间。别在 push 后立刻切到另一台机器验证，先等三分钟，再清缓存，再试。
