返回第十二卷 · Go 包与模块：01.09 · 依赖与工具：10.08 · CI 制品：10.09 · 版本回退：10.10

12.01 运行环境与制品：从 Go 二进制到可核对镜像

DeepTutor 八节初稿经技术与教学审阅后的静态课程。“网关”、构建记录、镜像标签和摘要均为虚构纸上示例；本仓库没有因此新增 IM 服务，也没有运行 Go 构建、制作镜像、启动容器、部署或构建站点。当前 S2 /v1 的正文仍非空且最多 6 UTF-8 B、原始 HTTP 请求正文最多 4096 B、同 ID 重复 409、非成员隐藏 404、成功 200 accepted_in_memory 仅表示本进程内存受理；未来 S3 /v2 的 stored_in_teaching_db 是提议且仍为 6 B，R9 6→9 B 待审。09.02 当前合同

一、同一个“版本”可能指六种不同对象

假想以后学习者把自己的 IM 网关部署在两个隔离环境。两边都说“我们跑的是 course-v1”，A 环境的 /v1 拒绝 9 B 正文，B 环境却接纳了 9 B。究竟是源码不同、Go 二进制不同、镜像标签漂移、启动配置不同、外部数据/权限不同，还是观察了不同接口版本？只看一个“版本号”回答不了。10.09 制品身份

对象	它实际是什么	单独不能证明
源提交	代码、构建定义和部分文档的版本坐标	编译环境/生成物与运行配置相同
Go 二进制	编译后的目标平台可执行文件	已用哪份运行配置、外部状态为何
OCI 镜像	文件层、镜像配置与 manifest 的内容集合	运行实例当前健康或 DB 数据状态
标签 course-v1	便于人指向镜像的可变名称	今天和上周指向同一内容
摘要 sha256:...	对相应 OCI 描述符内容的固定标识	容器用了相同配置/卷/外部依赖
运行容器/进程	镜像内容加启动参数、资源/权限/网络/挂载	其 HTTP 200 自动代表持久或设备收到

源码、制品、配置、数据、业务结果要顺着链路核对。镜像提供文件与默认运行参数，容器是按镜像启动的进程及其运行环境；权威消息历史、数据库、卷与设备状态通常在镜像外，不能因镜像可重建就认为数据可恢复。Docker 的入门文档将镜像描述为包含运行文件/默认配置的分层包；OCI 规范再精确定义 manifest、config 和 layer 的引用。Docker：What is an image? · OCI Image Manifest

二、Go 二进制的来源链：依赖校验不等于全部锁定

Go 初学者已经在 01.09/10.08 学过模块。未来要构建一个可核对二进制，至少要保留：源提交、go.mod、go.sum、生成代码来源、Go 工具链版本、构建标签/参数、目标 GOOS/GOARCH、编译产物身份。同一源码若工具链、生成器、构建参数或目标架构不同，产物可能不同；同一二进制复制到另一台机器，启动配置与外部依赖仍可能不同。Go Modules Reference · 10.08 MVS 与校验

go.mod 表示模块要求与 Go 版本等信息，Go 的模块选择还可能涉及传递依赖；go.sum 保存校验条目，可帮助验证下载模块内容，但不是所有依赖版本的一份完整、永远不变的锁文件。它可能保留当前构建不再需要的模块版本哈希，也不记录运行时 DB 配置或镜像基础层。不要因为两个仓库的 go.sum 文本相同就宣称二进制字节必相同。Go Modules Reference：go.sum

Go 标准库的 runtime/debug.ReadBuildInfo 或对文件使用 debug/buildinfo，可在条件具备时读取二进制内嵌的工具链、模块与部分构建设置；它不保证所有源码、生成器、私有配置、运行时环境或外部数据都被完整记录。学习者以后可在自己的隔离制品上核对这些字段，本章没有执行构建或读取真实二进制。Go runtime/debug.BuildInfo · Go debug/buildinfo

三、镜像的层、manifest、标签和摘要各负其责

OCI 镜像用层表达文件系统改动，用 config 表达入口命令、默认环境等镜像运行配置，用 manifest 引用 config 和层的内容描述符。按内容计算的 digest 有助于固定“拿到的是哪份镜像内容”；人类易读的 tag 则可被重新指向别的内容。不要把一个 Dockerfile 文件、一个 Go 二进制与完整 OCI 镜像画等号。OCI Config · OCI Manifest

设虚构注册表里标签 im-gateway:course-v1 在周一指向摘要 D1，周三被重新指向 D2。两个操作员都说“部署 course-v1”，却可能实际拉到不同内容；若回退时只再次使用 tag，甚至可能仍拉到 D2。需要记录解析后的 digest、目标平台和实际运行镜像身份，而不是只写 tag。Docker 的构建实践明确说明标签可变，按 digest 固定镜像则保留可追溯的内容坐标。Docker：Pin base image versions

更进一层，多平台镜像索引的 digest 可以固定一份“不同架构镜像列表”；在 linux/amd64 和 linux/arm64 上选中的具体平台 manifest/layers 可能不同。记录“D1 是索引 digest 还是平台 manifest digest”、实际平台，才能解释同一上层引用为什么运行不同架构二进制。初学者第一遍只需记：tag 是名字，digest 是相应内容，镜像还有平台选择；第二遍再沿 OCI 描述符追细节。OCI Image Index

固定摘要不等于永远不更新。固定基础镜像提高重建可追溯性，也可能把过时组件固定住；需要定期审阅升级并把新摘要作为受控变更。这里讨论的是制品供应链责任，不是建议本仓库现在构建或推送任何镜像。Docker：基础镜像更新与摘要

四、相同镜像 D1 为什么仍可能有不同业务结果

运行实例除镜像 D1，还读取启动环境、配置文件/挂载、凭据、网络与权限、外部依赖及其数据状态。例如日志级别和目标服务地址可以按环境配置；同一 D1 若连接到两份不同的教学 DB，m-9/seq9 是否存在会不同。镜像里装了一个数据库客户端，也不证明拟议 S3 /v2 已部署、持久承诺成立或 B 已收到。09.05 数据访问边界

纸上对照	相同项	不同项	可得结论
A/B 都用 D1	镜像字节	配置版本 K1/K2	要查启动参数与变更记录，不能只报“同镜像”
A/B 都用 D1+K1	镜像与配置	DB 中成员/消息状态	用户可见 404/历史结果仍可能不同
A/B 都用标签 T	tag 字面量	实际解析 digest D1/D2	二进制或基础层可能已变化
A/B 都用 D1+K1+同数据	前述条件	CPU 架构/配额/网络故障	性能与可用性仍要实测

有一条不可跨越的合同门：当前 /v1 正文上限是 6 UTF-8 B。若某个 BODY_LIMIT=9 环境变量或远端配置让 /v1 接受 9 B，就是合同漂移，不是“同一镜像因环境不同的合理差异”。R9 仍待审批，应由明确的新版本/能力合同决定，不能靠部署配置偷偷放宽旧路由。10.12 R9 影响评估

镜像文件层也不等于权威历史卷：容器重新创建时，进程内 S2 状态无跨重启保证；未来若使用持久卷/DB，则要按数据身份、权限、备份和版本迁移另验。把数据库文件烤进镜像当成“持久化方案”，会让制品更新、数据更新和恢复语义混乱。第十二卷后续再系统讲挂载与平台存储。03.12 进程退出后的业务恢复

五、构建变量不是存放秘密的地方

Docker 构建里的 ARG 与 ENV 各有作用，但不适合传密码、令牌等构建秘密：值可能留在镜像层、镜像配置、构建历史或来源记录。若构建确需访问私有依赖，应使用受控的构建 secret/SSH mount，使凭据仅在对应步骤短暂可用；运行时凭据也应由权限受控的外部机制注入，不写进 Dockerfile、代码、课程示例或普通日志。Docker 官方构建文档明确提醒 ARG/ENV 会暴露秘密。Docker：Build Variables · Build Secrets

配置来源可追溯，秘密值不必公开。 制品核对单可记录“使用配置版本 K1、凭据由哪个受控通道提供、允许访问哪类依赖”，但不打印凭据内容。相同镜像 digest 的容器如果启动时缺少必要权限，可能健康检查失败或在请求时 5xx；单看镜像 digest 不会发现。当前教学 S2 没有真实 DB 凭据或部署，本页不提供任何实际秘密值。09.07 身份与权限

六、把 C→B→D→K→用户结果排成证据链

用一张纸上制品卡，把构建与运行连接起来：

源提交 C + Go 工具链 G + 依赖/生成代码/构建设置
    → 二进制 B（可读的 BuildInfo 只是部分证据）
    → OCI 镜像摘要 D1（tag T 仅是可移动名字）
    → 平台/架构 A + 运行配置 K + 外部数据状态 S
    → 当前 /v1 业务合同实际结果

证据字段	纸上记录方式	不能遗漏的疑问
源与构建	提交 C、工具链 G、生成器/模块、目标平台、二进制 B	工作区/生成文件是否与提交一致？
镜像	tag T、解析的 D1、基础层与平台	T 后来是否移到 D2？多平台选了哪个 manifest？
运行	配置版本 K、资源/网络/身份、受控秘密来源	是否在错误环境读了不该读的配置？
外部状态	DB/卷/成员权限的来源与版本	m-9 或 u-c 权限结果为何不同？
业务验证	6 B 正例、9 B 当前拒绝、重复 409、非成员 404、200 只内存受理	有没有把拟议 S3/R9 写成已生效？

D1 相同但 K 不同时，先查配置是允许差异还是合同漂移；T 相同但 D1/D2 不同时，先查标签移动与发布记录；D1/K 相同但 S 不同时，检查有权数据范围。让排障者能逐步缩小范围，比“镜像没变所以不可能是发布问题”更可靠。10.09 制品身份

七、回退镜像也要评审配置、数据与旧客户端

如果未来发布后需要回退，按已知 digest选择旧候选，只解决“代码/镜像内容退回”；配置 K 可能也已更新，数据库模式/事件数据可能已前进，旧客户端支持窗口和 R9 待审状态也各自独立。回退前要对照“旧二进制能否读新数据/配置，当前 /v1 6 B/409/404/200 合同是否守住，未来 S3 权威记录是否需要迁移/对账”。不能把 tag 改回 course-v1 就宣称数据可逆。10.10 四轴发布与回退

本章的验收仍是静态清单：若学习者未来有隔离的个人实现，可核对提交、构建信息、镜像 digest、运行配置来源和有权限的 API 正反例；实际服务/容器/数据库运行结果要另留证。当前仓库只有课程和既有本地学习材料，没有在本章生成可部署 IM 网关。09.12 服务项目课程

固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定分支调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。它们只支持所读发送与消费的异步边界，不能证明该公开项目的镜像标签、digest、构建工具链、配置/秘密或运行集群状态，也不能替本课程项目凭空生成这些制品。OpenIM 阅读地图

八、22 道分层练习：交一张制品/配置/数据核对卡

先写出每题所问的对象，再展开反馈。

基础 1–8：辨认对象

1. Go 源码与编译后二进制是同一对象吗？

不是。源码还要经工具链、依赖、生成代码和构建设置形成目标平台二进制。

2. OCI 镜像等于运行中的容器吗？

不等于。容器按镜像加运行配置、权限、网络和挂载启动进程。

3. 镜像文件层自动保存未来权威消息历史吗？

不自动。数据库/卷与进程内状态要另定义数据身份和恢复合同。

4. tag `course-v1` 必然永远指向同一镜像吗？

不必然。tag 可重指向，应记录解析的 digest。

5. digest D1 与 tag T 的首要区别是什么？

D1 是相应内容标识；T 是方便引用、可移动的名字。

6. `go.sum` 是完整运行环境锁文件吗？

不是。它校验模块内容，但不锁镜像、工具链全部细节、运行配置或 DB 状态。

7. `ReadBuildInfo` 能保证读出全部源码和运行秘密吗？

不能。它提供二进制内嵌的部分构建信息，不覆盖全部源码、配置或外部数据。

8. 当前 S2 的 200 是存数据库成功吗？

不是。它只表示本进程内存受理。

路径 9–16：分析同名或同摘要反例

9. 两环境都部署 tag T，A 解析 D1、B 解析 D2，代码一定相同吗？

不能断定。T 指向的内容在两次解析时不同，应查发布记录和 digest。

10. A/B 都用 D1，但配置 K1/K2 不同，结果一定相同吗？

不一定。启动配置可能改变允许的环境行为；公开合同漂移仍属错误。

11. 同 D1+K1，但两环境 DB 成员状态不同，非成员 404 结果可不同吗？

有权成员与非成员身份不同会影响授权结果；须对照相同主体/会话的数据状态，不能只查镜像。

12. `BODY_LIMIT=9` 让当前 `/v1` 接纳 9 B，能作为合理环境差异吗？

不能。这违反当前 6 B 合同，R9 仍待审。

13. 同一个多平台索引 digest 在 amd64/arm64 下必选同一平台二进制吗？

不必。索引可指向不同平台 manifest，需记录实际平台和所选镜像。

14. Dockerfile 的 ARG/ENV 可以安全存构建密码吗？

不应。可能暴露在镜像/元数据或历史中，构建秘密用受控 secret mount。

15. 固定基础镜像 digest 后就无需审更新了吗？

不是。固定有助追溯，也要定期评审新版本与安全修复。

16. 同 D1 重新创建容器可保证旧 S2 内存消息还在吗？

不能。当前 S2 无跨进程持久承诺。

决策 17–22：可复核发布和回退

17. 制品卡最少应关联哪些构建来源？

源提交、Go 工具链/目标平台、模块/生成代码、构建参数和二进制身份。

18. 为什么运行实例还要记录配置版本和秘密来源？

同镜像可因配置/权限不同而行为不同；记录来源即可，不暴露秘密值。

19. 回退时只把 tag T 改回旧名字就够吗？

不够。要固定实际旧 digest，并审配置、数据、旧客户端与状态兼容。

20. 未来 S3 200 可由镜像内有 DB 驱动直接证明吗？

不能。要有批准的接口/提交合同及真实运行证据。

21. OpenIM 两处固定源码能证明其镜像 digest 或本项目运行配置吗？

不能。只支持所读发送与 Mongo 消费的异步边界。

22. 一张可审的运行制品交接卡交什么？

源码/二进制/镜像 digest、tag 与平台、配置与秘密来源、外部数据身份、当前业务正反例、回退兼容和未验证项。

本章完成标准与后续路径

能从提交 C 追到二进制 B、镜像摘要 D1、运行配置 K 和外部状态 S，解释同 tag 不同内容与同 digest 不同结果，并守住当前 /v1 的 6 B/409/404/内存受理合同，才算完成第一轮。本页没有构建或部署 IM 制品。下一章12.02 容器机制再拆镜像文件层、容器进程、namespace/cgroup、volume 与信号，解释容器重建后哪些东西还在。