1. 当你的Erlang应用开始"闹脾气"
去年我们的实时聊天系统升级时，曾经遇到过这样一个诡异现象：测试环境运行完美的消息队列模块，在生产环境突然频繁崩溃。经过三天三夜的排查，最终发现是某个间接依赖的JSON解析库在Erlang/OTP 24和25版本中表现出不同的行为特征。这个案例让我深刻认识到——依赖管理就是现代Erlang开发的暗礁区。
2. 依赖冲突的三大典型场景
2.1 版本叠加冲突
当两个依赖同时要求不同版本的公共库时，就像两个朋友分别要你穿西装和运动服参加同一个聚会。例如我们的消息推送服务依赖的gun客户端和hackneyHTTP库对cowlib的版本要求：
%% rebar.config片段
{deps, [
{gun, "2.0.0"}, % 依赖cowlib 2.9.0+
{hackney, "1.18.1"} % 依赖cowlib 2.8.0
]}.
2.2 循环依赖陷阱
在开发监控系统SDK时，我们曾创建了这样的依赖链：
app_a -> app_b -> app_c -> app_a
这种俄罗斯套娃式的依赖会导致Rebar3在编译时陷入死循环，报错信息却只显示"undefined function"这类误导性提示。
2.3 环境不一致的暗雷
CI服务器使用Erlang/OTP 25编译的release包，在运行环境使用OTP 24时可能因为NIF模块不兼容导致段错误。某次线上事故的堆栈信息显示：
eheap_alloc: Cannot allocate 123456 bytes of memory (of type "old_heap")
3. Rebar3的十八般武艺
3.1 锁定依赖版本
生成可靠的lock文件是解决冲突的基础。在项目根目录执行：
rebar3 lock
生成的rebar.lock文件相当于项目的DNA图谱：
{"1.2.0",
[{<<"ranch">>,{pkg,<<"ranch">>,<<"1.8.0">>},0},
{<<"cowlib">>,{pkg,<<"cowlib">>,<<"2.9.1">>},1},
...
]}.
3.2 依赖覆盖的精准调控
在rebar.config中使用override指令强制指定版本：
{overrides, [
{override, cowlib, "2.9.1"} % 解决gun和hackney的版本冲突
]}.
3.3 条件依赖的智慧
根据OTP版本动态加载依赖：
{deps, [
{parse_trans,
{git, "https://github.com/uwiger/parse_trans.git",
{ref, "3.3.0"}},
{otp_release, ">= 24"}} % 仅在OTP24+环境加载
]}.
4. 实战：构建高可用配置中心
我们以分布式配置中心为例，演示如何处理复杂依赖链。假设需要整合以下组件：
{deps, [
{ekka, "0.15.3"}, % 集群管理
{eredis, "1.2.0"}, % Redis客户端
{jiffy, "1.0.6"}, % JSON解析
{poolboy, "1.5.2"} % 连接池
]}.
4.1 依赖树可视化
使用Rebar3插件生成依赖图谱：
rebar3 tree
输出显示eredis间接依赖的goldrush与ekka依赖的sasl存在版本冲突。
4.2 分层依赖管理
创建apps/目录实现模块化：
.
├── apps/
│ ├── config_loader/ % 配置加载模块
│ └── cluster_manager/ % 集群管理模块
└── rebar.config
每个子应用维护自己的依赖配置，顶层通过deps_dir统一管理。
4.3 热升级的依赖隔离
在sys.config中为不同模块指定代码路径：
[{kernel, [
{code_paths, [
"/lib/ekka-0.15.3/ebin",
"/lib/eredis-1.2.0/ebin"
]}
]}].
5. 关联技术深度解析
5.1 Hex.pm的版本仲裁机制
Hex的版本解析算法采用语义化版本控制：
~> 2.3允许2.3.0 ≤ version < 3.0>= 1.0.0 and < 1.1.0精确匹配次要版本
5.2 OTP应用的版本兼容性
通过app.src文件声明兼容性：
{application, myapp,
[{applications, [kernel, stdlib]},
{vsn, "1.2.3"},
{min_otp_vsn, "24.3"} % 最低OTP版本要求
]}.
6. 应用场景全解析
6.1 微服务架构中的依赖矩阵
在包含20+微服务的系统中，使用全局依赖管理文件：
%% global_deps.config
{erl_opts, [debug_info]}.
{deps, [
{lager, "3.8.0"},
{jsx, "3.0.0"}
]}.
各服务通过继承机制复用配置：
{extends, "../global_deps.config"}.
{deps, [
{specific_lib, "1.0.0"}
]}.
6.2 CI/CD中的依赖缓存
在GitLab CI中配置高效缓存策略：
cache:
key: $CI_PROJECT_NAME
paths:
- _build/
- ~/.cache/rebar3/
policy: pull-push
7. 技术方案优劣对比
7.1 手动依赖管理 vs 工具自动化
手动管理示例：
{deps, [
{cowboy,
{git, "https://github.com/ninenines/cowboy",
{tag, "2.9.0"}}}
]}.
优势：完全控制版本 劣势：更新维护成本高
7.2 全局锁文件 vs 模块化锁文件
分模块锁文件结构：
project/
├── apps/
│ └── web/
│ └── rebar.lock
└── rebar.lock
优势：模块独立升级 劣势：依赖重复下载
8. 必须牢记的七条军规
- 生产环境永远使用
rebar3 as prod release - 定期运行
rebar3 update更新索引 - CI流水线强制检查锁文件差异
- 重要依赖必须指定上限版本
- 使用
rebar3 tree验证依赖树 - NIF依赖必须绑定OTP主版本
- 保留至少三个历史版本的lock文件
9. 从血泪教训中成长
某金融系统升级事件完整时间线：
Day1: 升级eredis到2.0.0 → 单元测试通过
Day2: 集成测试报错 → 发现依赖的poolboy接口变更
Day3: 回滚至1.2.0 → 发现lock文件未提交
Day4: 重建环境失败 → hex.pm的2.0.0版本被撤回
最终解决方案：在override中固定poolboy为1.5.1
10. 通往依赖安全的阶梯
建立企业级依赖管理体系的五个阶段：
青铜：手动维护deps目录
白银：使用rebar.lock文件
黄金：搭建内部hex镜像
铂金：自动化依赖审计
钻石：全链路版本溯源