1. 环境初始化与配置管理：服务器选型避坑、操作系统版本选择、环境变量污染、配置文件管理混乱
部署这件事，说白了就是把代码变成能跑的服务。但很多人第一步就栽了——服务器选型不对、操作系统版本踩坑、环境变量乱成一锅粥、配置文件散落一地。我见过太多团队，代码写得漂漂亮亮，一到部署就翻车。嗯，今天咱们就把这些坑一个一个填上。
1.1 服务器选型：别只看配置单
选服务器，不是看CPU核数多、内存大就完事了。你得想清楚业务场景。
核心原则：选型不是选参数，是选匹配度。
我个人习惯先问三个问题：
- 业务类型是什么？ 计算密集型（视频转码、科学计算）还是IO密集型（数据库、缓存）？
- 流量模型怎样？ 平稳型还是突发型？要不要弹性伸缩？
- 运维能力如何？ 团队有没有能力管理物理机？还是直接上云省心？
我在项目中遇到过一件事：有个团队买了高配物理机跑Nginx，结果CPU常年不到5%。说白了就是选型没想清楚，钱花了，性能浪费了。
| 场景 | 推荐方案 | 避坑点 |
|---|---|---|
| Web应用（中小型） | 云服务器 4C8G 起步 | 别买突发性能实例，跑起来限速 |
| 数据库（MySQL/PostgreSQL） | 高IO实例 + SSD | 别用共享型，IO争抢严重 |
| 缓存/消息队列 | 内存优化型 | 注意内存带宽，不是越大越好 |
| AI训练/推理 | GPU实例 + 高带宽网络 | 显存和算力要匹配，别头重脚轻 |
避坑指南：我曾经帮一个客户排查线上问题，发现他们的数据库服务器用的是"共享型"实例。一到业务高峰期，邻居实例一抢IO，他们的查询就慢成蜗牛。换了专用实例后，问题直接消失。选型时一定要看清楚实例类型说明，别被低价迷惑。
1.2 操作系统版本：稳定才是王道
操作系统版本怎么选？我的建议很简单：选主流LTS版本，别追新。
你想想看，生产环境最怕什么？最怕不兼容、没补丁、社区没人管。我见过有人用Debian Sid跑生产，结果一次滚动更新把内核搞崩了，整个服务挂了半天。
| 操作系统 | 推荐版本 | 说明 |
|---|---|---|
| Ubuntu | 20.04 / 22.04 LTS | 社区活跃，软件包新，适合通用场景 |
| CentOS / Rocky Linux | 7.9 / 8.x / 9.x | 稳定，适合传统企业，注意CentOS 8已停服 |
| Debian | 11 / 12 | 极其稳定，适合对稳定性要求极高的场景 |
| Alpine | 3.18+ | 体积小，适合容器镜像，但glibc兼容性要注意 |
小技巧：我个人习惯在选操作系统时，先去查一下目标软件的官方文档，看看他们推荐什么版本。比如Kubernetes官方就明确推荐Ubuntu 22.04或Rocky Linux 9.x。跟着官方走，一般不会错。
还有一个坑：操作系统版本的生命周期。 CentOS 8在2021年底就停服了，很多人还在用，结果安全补丁都没地方打。选版本前，先去查一下EOL（End of Life）时间，别选一个马上要过期的。
1.3 环境变量污染：看不见的杀手
环境变量这东西，看着简单，但坑特别多。我见过最离谱的一次：一个团队在服务器上配了全局的 JAVA_HOME，结果另一个应用需要不同版本的JDK，一启动就报错。查了两天才发现是环境变量冲突。
为什么会这样？因为环境变量是全局的，一旦污染，所有进程都会受影响。
核心原则：环境变量要按需加载，不要一股脑全塞进 /etc/profile 或 ~/.bashrc。
我建议的做法：
- 系统级变量：放在
/etc/environment，只放真正全局需要的（如PATH、LANG）。 - 应用级变量：用
.env文件，配合direnv或systemd的EnvironmentFile加载。 - 容器环境：通过 Docker Compose 或 Kubernetes 的 ConfigMap/Secret 注入。
# 不好的做法：把所有东西都塞进 ~/.bashrc
export JAVA_HOME=/usr/lib/jvm/java-11
export MAVEN_HOME=/opt/maven
export PATH=$JAVA_HOME/bin:$MAVEN_HOME/bin:$PATH
export MY_APP_SECRET=supersecret
# 好的做法：用 .env 文件 + direnv
# .env 文件内容
JAVA_HOME=/usr/lib/jvm/java-11
MAVEN_HOME=/opt/maven
# 注意：密钥不要放这里，用密钥管理服务
避坑指南：我曾经在排查一个"诡异"的Bug时发现，某台服务器上 PYTHONPATH 被全局设置成了某个旧项目的路径。结果新项目一导入模块，就加载了旧版本的代码。排查过程极其痛苦。从那以后，我坚持每个项目用虚拟环境或容器隔离，绝不共享环境变量。
1.4 配置文件管理：别让配置成为灾难
配置文件管理混乱，是部署中最常见的坑之一。我见过有人把配置文件直接放在代码仓库里，结果密钥泄露；也见过有人把配置文件散落在服务器各个角落，换台机器就找不到。
配置文件管理的核心就三点：版本化、集中化、安全化。
| 问题 | 表现 | 解决方案 |
|---|---|---|
| 配置散落 | 每个服务器手动改配置，不一致 | 用配置中心（Consul/Etcd）或Ansible统一管理 |
| 密钥泄露 | 数据库密码写在配置文件里，提交到Git | 用Vault/Secrets Manager，或环境变量注入 |
| 配置硬编码 | IP地址、端口写死在代码里 | 用配置模板 + 变量替换 |
| 版本混乱 | 不知道哪个配置对应哪个版本 | 配置文件和代码一起版本控制（不含密钥） |
小技巧：我个人习惯用 etcd + confd 做配置管理。配置变更后，confd自动检测并更新本地配置文件，然后重启服务。这样既保证了配置的集中管理，又避免了手动操作的失误。
还有一个容易被忽略的点：配置文件的权限。 很多人的配置文件是644权限，所有人都能读。如果配置文件里包含数据库密码、API密钥，那就等于把家门钥匙挂在门外。
# 配置文件权限建议
chmod 600 /etc/myapp/config.yaml # 只有属主能读写
chmod 640 /etc/myapp/config.yaml # 属主读写，属组读
# 如果必须让其他用户读，考虑用加密配置
# 或者用 systemd 的 LoadCredential 功能
1.5 知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个检查清单，每次部署前过一遍。
环境初始化这件事，看着琐碎，但每一步都关系到后续的稳定性。服务器选型想清楚业务场景，操作系统版本选LTS别追新，环境变量做好隔离，配置文件集中管理加权限控制。把这四点做到位，你的部署之路就稳了一半。
嗯，这一章就到这里。记住：部署的坑，90%都在初始化阶段埋下的。 前期多花点心思，后期少熬几个夜。