前文有说，因为 MinDoc 的调试/测试需要，搭建了个 docker 环境，在里面把 go、git 安装妥当，来开展工作。

实践中有个问题，操作起来觉得略显麻烦了些。源代码在宿主和容器里都有，在宿主里可以使用 Visual Studio Code 这样工具进行编辑，然后想办法同步到容器里进行编译运行。可是如果在测试过程中有一些小修小改都要这样搞的话，效率未免就太低了。于是就出现了直接在容器中使用 nano 之类的编辑器快速进行修改、编译的情况。这样告一段落之后，又需要把调试过的代码同步出 host 里来。

网上有人支招，用 ssh 相关的工具来解决，感觉重了些。后来发现 docker 有机制可以把 host 的目录加载到容器里，深得我心。详加考察后又略感沮丧，原来这个步骤要在容器创建时指定，一旦创建，在 start 的环节是无法补充执行的。三太爷作为：
资深三晋京飘、
重度拖延症患者、
极端强迫症患者、
前 C/C++ 程序员、
现 Android/Go/JavaScript/Objective-C/PHP/Python/Shell 业余程序员、
团队首席文档师、
精神黑客，这最后的一个头衔决定了要给容器做个小小的手术。

实用最朴素的技术思维来思考这个问题，这样的映射关系显然应该存储在容器自身的某个配置项里面。要想一睹真容，首先要创建一个具有此特性的容器。于是采用 docker create -v /home/dandy/Workspaces/code/go/src/:/root/playground/src –name dc_mindoc ubuntu 命令创建一个名为 dc_mindoc 的基于 Ubuntu 映像的容器。

做了一下功课，知道 docker 的大本营驻扎在 /var/lib/docker 路径下，只是要访问的话是需要 root 权限的。进去其中的 container 目录，根据创建时间应该立刻就能找到刚刚创建的容器所处的子目录，当然，你要能记得容器的 ID 那就可以直接杀入了。里面有五六个文件，两个 json 文件，一个 conf 文件看起来就很对眼。经过实际检测就会发现，resolv.conf 文件主要是网络域名解析相关的内容，暂时放过它。两个 json 文件一个名为 config.v2.json，一个名为 hostconfig.json，出于直觉，优先查看了后者。结果一打开发现，文件的第一个配置——名为 Binds 的数组——里面就放着目录的映射关系。到 MinDoc 容器的目录下做了相应修改，启动后发现无效。返回来接着检查 config.v2.json，果然又有发现，其中有个叫 MountPoints 的域，是这一映射的详细配置信息。于是又到 MinDoc 容器中照猫画虎，还是不行。后来想到也许是因为容器中的加载点没有预备妥当的缘故（因为想到了 mount 命令的实际情形），又手动到容器中创建了目标目录，还是不行。这三次失败的结果，除了容器中并未出现预期的目录被成功映射之外，还同时伴随有对于 json 文件的修改丢失的现象。

这下就迷茫了，一度开始怀疑自己的技术敏感度了。从单位回到家后到 GitHub 一直追踪 docker-cli 和 docker-ce 的源代码，也没看出个所以然来，后来实在是太晚了，凌晨两点半，而且白天还要上班，只好悻悻中止，上床睡觉，连最狠的准备都盘算过了，大不了下载 docker 源码，自己编译跟踪。

白天上班后，反省了一下冲动。认为当务之急还是搞定 MinDoc 想做的功能，而不是和 docker 较劲。于是又想出个笨招来，在终端下切入 root 身份，给 docker 里的目标目录在宿主里创建了个软链接，把 Beyond Compare 打开，左侧是 host 里的源代码目录，右侧是 container 里的源代码目录，用 VSC 修改之后从左侧同步到右侧，然后再到 docker 里编译运行。

编辑，保存。编译，运行。嗬，真有效果。一想，不对呀，我并没有把 host 里的源代码同步到 container 里面呀，见鬼了？一检查，还真是见鬼了。src 目录好端端地映射成功在那儿了！

目前正在享用着这个成果。为什么成功，并没有再次详细测试，但我老人家有十分把握，这个操作在必要时是可以成功复现的。如果要想象一下具体原因的话，个人认为是因为重启了一下电脑，docker 的 service 完全重新开始而引发的。也就是说，如果 docker 的 service 一直在运行状态的话，为一个容器（哪怕它已经 stop）增加目录映射是不能立刻生效的。