如果你同时维护RK3588、RV1126、RK3568的嵌入式开发环境，大概率经历过这种绝望：A平台的Dockerfile修了bug，B平台永远收不到同步；Ubuntu 24.04的改动能让20.04直接崩溃；最烦的是端口——两个容器同时跑，SSH端口撞车，文档写得再细也有人踩坑。
这套问题我磨了6个月，最后写了个叫HarborPilot的工具。核心思路不是堆文档，是把"平台差异"当成变量注入，而不是复制粘贴整份配置。
从6份Dockerfile缩成1份五层流水线
早期每个芯片一份Dockerfile，RK3588的修复漏到RK3568是常态。6个月后我换成单文件五阶段构建：基础OS、开发工具链、SDK初始化、环境配置、工作区+入口。平台差异全塞进ARG/ENV，构建时注入。
好处很实在。Ubuntu 24.04把Python 3.12设成默认、改了apt源格式、还动了systemd-resolved，这三处破坏性变更不用开新分支，条件判断就能兼容老版本。
关键认知：平台不是文件，是配置层的叠加。
我拆了三层继承：configs/defaults放10个领域范围的默认值，configs/common.env锁死项目版本和常量，configs/platforms/*.env只写覆盖项。一个RK3568平台文件长这样：
PRODUCT_NAME="rk3568-rk3568_ubuntu-20-04"
CHIP_FAMILY="rk3568"
OS_VERSION="20.04"
PORT_SLOT=2
HAS_PROXY=true
就6行。剩下全从上层继承。加新平台？15-20行配置，向导自动检测PORT_SLOT冲突。
PORT_SLOT：一个整数解决端口地狱
同时跑多容器的人懂这个痛：RK3588和RK3568都默认抢2109端口做SSH。以前要么写死文档（没人看），要么手动改（必出错）。
我搞了个PORT_SLOT机制。一个整数派生所有端口：
CLIENT_SSH_PORT = 2109 + PORT_SLOT × 10
GDB_PORT = 2345 + PORT_SLOT × 10
RK3588给0，RK3568给2，端口自动错开40个单位。零冲突，零文档，新人来了不用问"我SSH连哪个口"。
这个设计偷师了VLAN的编号逻辑：用稀疏索引给扩展留空间，而不是连续挤在一起。
CLI设计：交互留给人类，脚本留给CI
HarborPilot的入口分两条线。./harbor走交互：选平台→构建→打标签→推Harbor仓库→校验manifest摘要，一步一确认。./ubuntu_only_entrance.sh start直接起开发容器，本地Ubuntu宿主即开即用。
CI场景用./scripts/create_platform.sh --non-interactive，参数全走命令行，流水线里无感集成。
工具本身不创造新抽象，只是把"复制6份配置"改成"写6行覆盖"。省下的精力可以去做更无聊的事——比如测试。
现在的问题是：你的团队还在用文档约束端口分配，还是已经上了某种自动化方案？如果手动维护超过3个嵌入式平台，PORT_SLOT这种模式值得抄作业吗？
热门跟贴