`pip install -e .`可编辑安装存在性能、部署等方面的弊端吗？

性能层面的缺陷 #

• 正常业务运行阶段无明显性能差异：可编辑安装的核心逻辑是在Python的site-packages目录下生成.egg-link链接文件指向你的本地源码目录，运行时和传统安装把代码复制到site-packages的执行逻辑完全一致，不会带来额外的CPU、内存开销。
• 仅模块导入阶段存在极小的潜在耗时差：如果你的源码目录放在低速存储（网络挂载盘、老旧机械硬盘），或者目录存在大量冗余无效文件，导入模块时的路径查找耗时会略高于传统安装，普通业务场景下这个差异基本感知不到，不会影响实际业务性能。

部署环节的弊端及安装方案 #

• 生产部署绝对不建议直接使用可编辑安装，核心弊端有两个：
  • 代码变更不可控：可编辑模式绑定的是本地目录代码，部署后如果该目录被误修改、同步了未测试的开发代码，会直接改变生产环境的运行逻辑，故障排查难度极高。
  • 依赖一致性无法保障：可编辑安装不会强制校验依赖版本匹配度，开发环境的本地修改不会触发依赖检查，直接沿用至生产很容易出现依赖版本冲突问题。
• 无需额外编写定制化安装代码，直接使用标准pip命令即可完成传统安装：你可以把两个关联仓库的代码打包为wheel包安装，或者直接通过仓库地址执行pip install <git仓库地址/本地代码目录路径>，都是标准的传统安装逻辑，成本极低。

其他潜在风险说明 #

• 安全风险：可编辑模式绑定的代码目录如果开放了写入权限，任何有权限访问服务器的用户都可以修改业务运行代码，存在恶意代码注入、代码被篡改的风险，不符合生产环境安全合规要求。
• 权限风险：如果源码目录放在普通用户的私有目录下，而业务服务使用低权限用户启动，很容易出现代码读取权限不足的报错，排查成本很高。
• 容器化场景风险：容器环境下使用可编辑安装需要把本地代码目录挂载到容器内，首先会破坏容器镜像的不可变性，同一个镜像在不同环境挂载不同代码会导致运行结果不一致，完全失去容器化的优势；其次在K8s等编排环境中挂载本地目录会限制节点调度，降低集群可用性。

开发阶段使用可编辑安装的效率优势很明显，生产环境必须切换为传统安装模式，保证代码和依赖版本完全固化即可。

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