由于某种原因，zavr的答案（使用README和README.md）在我尝试时不起作用（可能是NPM使用的逻辑发生了变化）。但真正起作用的是将GitHub README放入.github目录（根据他们的docs，这是允许的），并使用根README.md作为NPM的版本，沿着

<!-- README for NPM; the one for GitHub is in .github directory. -->

<badges>

<a brief description>

Please refer to the [GitHub README](https://github.com/<your repo>#readme) for full documentation.

幸运的是，对于GitHub，.github/README.md似乎优先于README.md。
更新2021-02-06：关于最佳实践的简要说明。NPM不会让你在不升级包版本的情况下更新自述文件，实际上你经常需要对文档进行更新，有时是小的更新。所以我建议在GitHub自述中提供完整的文档，但仍然给予NPM上的库的简短描述，结合package.json的keywords字段将使包更容易理解。在NPM自述文件中包含徽章也是一个好主意，因为这将增加NPM显示的质量分数（请参阅本文中关于“品牌”分数的讨论）。

问得好伙计！我更喜欢GitHub而不是NPM，原因有很多，比如
a）NPM上的列变窄，所有表开始滚动b）当图像从左到右对齐时没有填充c）TOC导航不起作用，因为锚链接在GitHub和npm上的生成方式不同
所以我找到了一个解决方案：添加一个README文件，NPM将读取该文件，并保留README.md文件，GitHub将读取该文件。很容易，但不能保证它会继续工作。

一种解决方案是使用两个自述文件，并在npm publish期间使用npm脚本重命名它们。
这可以如下完成。
在源代码控制中，我们会有以下文件：

*README.md-这是默认的git自述文件，您可以在其中记录源代码。
*npm.README.md-这将是NPM上的自述文件。

接下来，我们将在package.json中有以下内容（注意，省略了一些内容）。

{
  ...    
  "scripts": {
    ... 
    "build": "...",
    "use:npmReadme": "mv 'README.md' 'git.README.md' && mv 'npm.README.md' 'README.md'",
    "use:gitReadme": "mv 'README.md' 'npm.README.md' && mv 'git.README.md' 'README.md'",
    "prepublishOnly": "run-s build use:npmReadme",
    "postpublish": "npm run use:gitReadme"
  }, 
  "dependencies": {
    ... 
  },
  "devDependencies": { 
    ... 
    "npm-run-all": "^4.1.2", 
    ...
  }
}

在开发环境中，使用npm-run-all包。这允许使用run-s命令顺序运行指定的npm脚本。
在scripts部分，我们有以下脚本：

转换为README文件

• use:npmReadme-这只是备份当前git特定的自述文件，然后将npm.README.md重命名为默认的README.md。
• use:gitReadme-这只是恢复到使用git特定的自述文件作为默认的README.md。
  Previous

这是在准备和打包软件包之前执行的，并且仅在npm publish上执行。（不支持npm install）。
在这里，构建了解决方案，然后我们运行use:npmReadme。

postPublish

这是在包发布到npm之后执行的。
在这里，我们运行use:gitReadme将自述文件恢复到其原始状态。
有关prepublishOnly和postPublish的更多信息可以在here中找到。

keshav.bahadoor's的回答启发了我在GitHub工作流中使用类似的方法。
我使用它如下：

- uses: actions/checkout@v2
  ...
  - run: mv NPM-README.md README.md
  ...
  - run: npm publish --access public

我只在工作流期间将NPM-README.md移动到README.md，而不是提交。
其余部分workflow yaml file
注意：这适用于GitHub工作流，在本地使用没有意义。

1.* （更好的一个）* 如果我们将npm自述文件命名为README.md，将GitHub自述文件命名为readme.md。然后我们可以为npm添加readme.md忽略.npmignore，并为gitignore .gitignore添加README.md。
1.* （更坏的一个）* 加上npm.README.md和git.README.md。在提交或发布git或npm时删除npm.或git.。

这取决于你为什么要这么做。像libsquoosh这样的项目将子目录作为自己的库公开，同时仍然正常导入它们，导致这种结构：

├── cli
│   ├── index.js
│   ├── package.json
│   └── README.md
│
├── libsquoosh
│   ├── index.js
│   ├── .npmignore
│   ├── package.json
│   └── README.md
│
├── src
│   └── index.js
│
├── package.json
└── README.md

然后从src的主应用程序中通过以下方式正常导入库：
import x from ../mySubdir/index.js
但是从外部项目中，您可以将其导入为：
import x from @namespace/mySubdir
然后src目录不会被发送到NPM，只有两个子目录被发送到NPM，它们都有自己完全不同的README文件。与此同时，git root还有第三个README。
请注意，每个子目录都有自己的package.json和.npmignore文件，尽管它们是更大项目的一部分。
这样做的效果与上传到NPM的东西与你在git项目的根目录中看到的不同，但是免费添加了清晰的层次结构。