sublime text 无法直接连接 docker 容器开发，推荐用 sublime 编辑代码、脚本驱动沙箱运行；若必须 ssh，则需选用非 alpine 镜像、显式生成 host key、前台运行 sshd 并正确配置 remote - ssh。
Sublime Text 本身不支持直接连接 Docker 容器进行开发，所谓“容器内开发”必须依赖外部桥梁——最可行、最低侵入的路径是用 Remote - SSH 插件 + 容器内启用 SSH 服务。但这条路在微服务沙箱场景下极易踩坑，不推荐作为主力方案。
为什么 Sublime + Docker 的组合在微服务沙箱中天然受限
微服务沙箱（如 superradcompany/microsandbox）强调轻量、临时、按需启动，而 Sublime 的 Remote - SSH 要求：容器必须长期运行、开放 SSH 端口、预装 openssh-server、配置用户与密钥——这与沙箱“启动即用、关机即毁”的设计哲学冲突。
常见错误现象包括：
- 容器因无前台进程退出，SSH 连接瞬间断开
-
sshd启动失败，报错Could not load host key或No supported key exchange algorithms - Sublime 连上后无法读取挂载的代码目录（权限被
USER指令锁死） - 多个微服务沙箱并行时，SSH 端口手动映射易冲突（如都映射到
2222）
真正可落地的替代方案：用 Sublime 编辑，用脚本驱动沙箱
放弃“在容器里编辑”的执念，转而让 Sublime 专注写代码，把沙箱当作纯运行/调试环境。这是更符合微服务开发节奏的做法。
实操建议如下：
- 保持代码在宿主机目录（如
./orderservice），用docker run或docker-compose up启动沙箱时，通过-v $(pwd):/workspace挂载进去 - 在沙箱镜像的
ENTRYPOINT或启动脚本中，自动执行cp -r /workspace/. /app/（或按框架约定复制），确保代码生效 - 为每个微服务写一个轻量
run-sandbox.sh脚本，封装常用参数：--rm、-p 8080:8080、-e MOCK_USER_SERVICE=error等 - 在 Sublime 中安装
Terminal插件，右键菜单一键执行该脚本，输出实时显示在 Sublime 内置终端
如果坚持要 SSH 连容器，必须绕过三个关键陷阱
若因历史项目或团队规范必须走 SSH 路径，请严格遵循以下条件，否则大概率失败：
- 基础镜像不能用
alpine（默认无openssh-server），改用ubuntu:22.04或debian:bookworm - Dockerfile 中必须显式生成 SSH host key：
RUN ssh-keygen -A && mkdir -p /var/run/sshd - 容器启动命令必须是前台运行
sshd：CMD ["/usr/sbin/sshd", "-D", "-e"]，不能用service ssh start && tail -f /dev/null - Sublime 的
Remote - SSH配置中，host填localhost，port填你-p映射的宿主机端口（如2222），user填镜像中创建的非 root 用户（避免权限拒绝）
微服务沙箱的价值在于快速验证服务行为，而不是把编辑器塞进容器。越想“完全容器化”，越容易在 SSH 配置、用户权限、进程守护这些边缘问题上卡住半天——把 Sublime 当作干净的编辑层，把沙箱当作可靠的执行层，才是轻量级落地的关键。
