npm publish报invalid package name错误是因为name字段含大写字母或下划线，必须全小写、仅含a-z0-9和单连字符、不以-开头结尾、长度≤214字符。
npm publish 时提示 Invalid package name 或 package name must be lowercase
这是最典型的标签格式错误触发的失败。npm 对 name 字段有严格校验：必须全小写、不能含大写字母或下划线、长度不能超 214 字符、不能以点或下划线开头。很多人在本地开发时用 MyModule 或 my-module_v2，一到 publish 就卡住。
实操建议：
- 打开
package.json，检查"name"字段值 —— 用正则^[a-z0-9\-]+[a-z0-9\-]*$手动验证（开头结尾不能是-，也不能连续两个-） - 别依赖 IDE 自动补全或复制粘贴 —— 比如从 GitHub 仓库名直接拷贝
My-Project，会因首字母大写被拒 - 若想保留语义区分，用短横线代替下划线或空格：
my-awesome-tool✅，my_awesome_tool❌
Git 标签名和 npm 版本号不一致导致 npm publish --tag next 失败
当你用 git tag v2.1.0 打了标签，但 package.json 里还是 "version": "2.0.0"，npm 会拒绝发布 —— 它默认只允许发布与当前 version 字段完全匹配的包。
常见错误现象：执行 npm publish 后报错 EPUBLISHCONFLICT 或提示 “You cannot publish over the previously published version”。
实操建议：
- 发布前务必同步三处：
package.json#version、git tag名、npm view your-pkg versions中已存在版本列表 - 不要手动改
package.json再git commit—— 推荐用npm version patch（自动更新版本 + 提交 + 打 tag） - 如果要用
--tag发预发布版（如next），确保version字段带预发布标识："2.1.0-beta.1"，而非单纯"2.1.0"
私有模块误用 public registry 的标签策略
在私有 registry（如 Verdaccio、Nexus）上发布时，若沿用 public npm 的 latest/next 标签逻辑，但服务端未开启对应 tag 权限或配置了 strict mode，就会返回 403 Forbidden 或 Cannot publish over existing version。
关键差异在于：public npm 允许任意用户对自有包设置 latest，而多数私有 registry 默认禁用 tag 写入，仅允许 publish 不带 --tag 的请求。
实操建议：
- 先查 registry 配置 —— 看
allow_publish_for或packages规则是否放开了tags操作 - 发布私有模块时，优先不加
--tag参数，让 registry 自动绑定到latest（前提是权限允许） - 若必须指定 tag，确认命令中 registry 地址正确：
npm publish --registry https://your-registry.com --tag dev，漏掉--registry会默认走 public npm
Windows 下路径大小写混用引发 tarball 校验失败
在 Windows 上构建的包，若文件路径含大小写混用（比如 src/Utils/Helper.js 和 src/utils/helper.js 同时存在），打包后生成的 tarball 可能因文件系统不敏感导致重复 entry 或缺失校验和，npm publish 时校验失败并报 integrity checksum failed。
这不是 npm bug，而是底层 tar 工具在 case-insensitive 文件系统上生成的归档不满足 npm 的严格哈希验证要求。
实操建议：
- 发布前运行
npm pack，解压生成的.tgz，检查内部路径是否统一小写、无冲突重名 - CI 环境强制使用 Linux runner（GitHub Actions 中选
ubuntu-latest），避免 Windows 路径陷阱 - 在
.npmignore或files字段中显式声明要包含的路径，减少意外纳入的大小写变体文件
