如何不将Composer包保存至composer.json/lock中进行安装？

首先，你碰到的确实是Composer的正常逻辑：只要依赖项还在composer.json和composer.lock里，执行install或update时，Composer就会严格按照锁文件的版本重新部署，直接覆盖你本地的修改。要让这个主题脱离Composer的管控，你需要彻底把它从依赖列表中移除，同时保留自己的自定义内容。下面是两种可行的解决方法：

方法一：彻底移除依赖+迁移到自定义目录（推荐） #

这是最符合Drupal最佳实践的方式，能从根源避免后续的覆盖问题：

1. 先备份修改后的主题
   把当前主题文件夹（比如web/themes/contrib/my-theme）复制到本地安全位置，防止操作失误丢失自定义内容。
2. 从Composer中移除主题依赖
   执行这条命令，它会同时更新composer.json和composer.lock，并删除Composer管控的主题文件：

   composer remove my-package/my-theme
   

3. 恢复自定义主题到专属目录
   把你备份的主题文件夹移动到Drupal的web/themes/custom/目录——这是官方推荐的自定义主题存放位置，Composer默认不会对这个目录下的内容进行管理，后续再执行composer install/update时，完全不会影响这里的文件。
4. 重新配置Drupal主题
   登录Drupal后台，重新启用这个迁移到custom目录的主题，确保系统能正确识别并加载它。

方法二：手动清理依赖记录（不移动目录） #

如果不想调整目录结构，也可以手动清理Composer的依赖记录：

• 打开composer.json，找到require或require-dev里的"my-package/my-theme": "*"条目，删掉后保存文件。
• 打开composer.lock，搜索所有包含my-package/my-theme的内容（包括整个包的信息块），全部删除后保存文件。
• 执行以下命令清空Composer缓存，确保它不会再读取旧的依赖信息：

  composer clear-cache
  

  之后再执行composer install，Composer就不会再处理这个主题，你的自定义修改也不会被覆盖了。

额外提醒 #

• 一旦把主题从Composer依赖中移除，后续就没法通过Composer更新这个主题的官方版本了——如果之后需要更新，你得手动下载新版本，再合并自己的自定义修改。
• 尽量遵循Drupal的目录规范：第三方主题/模块放在contrib目录（交给Composer管理），自己修改或开发的放在custom目录（手动管理），能减少很多不必要的冲突。

内容的提问来源于stack exchange，提问作者Corentin Le Fur