嘿，这个坑我之前踩过！直接改node_modules里的文件简直是给自己埋雷——毕竟这个目录设计出来就是用来存自动安装的依赖，部署时肯定会被npm install重置，哪怕你把它从.gitignore里拿掉也没用（毕竟node_modules里有太多冗余文件、平台专属编译产物，提交到Git不仅会让仓库臃肿，很多平台部署时还是会强制重新安装依赖）。给你几个靠谱的解决方案，按推荐程度排序：

1. Fork原包并维护自己的版本（最规范、最可持续） #

这是长期来看最稳妥的方式，适合需要持续维护修改的场景：

• 去原包的代码仓库（比如GitHub）fork一份到你自己的账号下
• 在你的fork仓库里修改需要调整的代码，提交并推送到远程
• 把项目package.json里的原包依赖替换成你fork后的仓库地址，比如：

  "dependencies": {
    "原包名称": "git+https://github.com/你的用户名/你的fork仓库名.git#你的分支名"
  }
  

• 这样不管是本地还是部署环境，npm install都会拉取你修改后的版本，完全一致
• 后续原包有更新时，你还可以把上游的代码合并到自己的fork里，保持功能同步

2. 使用patch-package打补丁（适合小改动，快速解决） #

如果只是微小改动，不想折腾fork仓库，用patch-package绝对是最优解：

• 先安装它作为开发依赖：

  npm install patch-package --save-dev
  

• 本地修改完node_modules里的目标文件后，运行命令生成补丁文件：

  npx patch-package 原包名称
  

• 项目根目录会生成一个patches/文件夹，里面就是记录你修改内容的补丁文件，把这个文件夹提交到Git
• 在package.json的scripts里加一个postinstall脚本，让部署时自动应用补丁：

  "scripts": {
    "postinstall": "patch-package"
  }
  

• 这样部署时，npm install完成后会自动执行这个脚本，把你的修改补丁应用到新安装的依赖上，效果和本地完全一样

3. 把修改后的包作为本地依赖（仅临时场景用） #

如果只是临时测试，或者完全私有、不需要协作的小项目，可以试试这个方法，但不推荐长期用：

• 把修改后的整个包文件夹复制到你项目的某个目录，比如./local-packages/原包名称
• 在package.json里用本地路径作为依赖：

  "dependencies": {
    "原包名称": "file:./local-packages/原包名称"
  }
  

• 缺点很明显：包体积会让你的项目变大，没法同步原包的更新，团队协作也很麻烦，所以只适合临时救急

最后再提醒一句：绝对不要尝试提交整个node_modules到Git，不仅会把仓库搞炸，很多部署平台还会忽略你提交的node_modules，强制重新安装依赖，白忙活一场。

内容的提问来源于stack exchange，提问作者Atzuki