## 先问状态在哪
容器化的前提是状态外置。会话、上传文件、任务队列这些落在本地磁盘的内容，如果不先搬到数据库或共享存储里，容器一重启就丢。评估时逐项列出系统写入本地路径的位置，任何一处说不清用途的写入，都要先弄明白再谈打包。
## 依赖盘点
老系统常见的坑是隐式依赖：编译时链接的本地库、手工打过补丁的二进制、依赖特定内核版本的行为、写在文档之外的环境变量。逐条记录应用从启动到正常服务之间的全部外部依赖，包括它调用的系统命令与字体、编码这类小角色。盘点不完整的系统，进了容器也跑不安稳。
## 镜像老化问题
镜像一旦构建完成就开始老化。基础系统停止维护、依赖组件漏洞累积、构建脚本散落在个人机器上，都会让半年后想改一行配置时无从下手。评估阶段就要想清楚镜像的构建方式是否可重现，基础镜像是否有维护周期，谁来负责定期重建，这三个问题没有答案，容器化只是把技术债换了张皮。
## 不适合就不硬改
并非所有系统都值得容器化。变更频率极低、依赖硬件授权、需要直接操作特殊设备的系统，容器化收益有限而风险实在。这类系统继续跑在顺云云服务器的传统部署形态下，配合定期快照，反而更省心。评估清单过完，能回答状态、依赖、镜像、维护四类问题，容器化才具备基本条件；答不上来的条目，就是动手前要先补的功课。评估阶段还建议做一次试运行：用容器在测试环境把系统跑起来，观察一到两周，登录路径、定时任务、日志输出逐项与原环境比对，差异都记录成清单。真容器化时按清单补齐，比边迁边猜稳得多。评估拖住的不是进度，而是返工的成本。