对于服务器部署，代码存放的目录选择至关重要，它直接关系到安全性、可维护性、遵循标准和未来扩展性。生产环境中，最推荐、最符合Linux/Unix文件系统层次标准（FHS）且广泛实践的代码存放目录是 /var/www/（适用于Web应用）或 /srv/（更通用的服务数据目录），对于追求更高隔离性和现代部署方式的场景，自定义目录（如 /app/）或容器化部署（如 /opt/ 内）也是优秀选择。
核心目录选项详解与最佳实践
遵循标准 – /var/www/ (Web应用首选)
- 依据与优势:
- Linux FHS 标准：
/var目录明确设计用于存放系统运行过程中经常变化的文件（Variable files），如日志、缓存、假脱机文件等，其子目录/var/www是约定俗成存放网站根目录和Web应用程序代码的地方,遵循标准能让其他管理员或自动化工具更容易理解和维护您的服务器。 - 广泛支持： 绝大多数Web服务器（Apache, Nginx）的默认配置都预期网站文件位于类似
/var/www/的路径下，许多部署脚本、控制面板（如cPanel, Plesk）也默认使用此目录。 - 权限管理清晰： Web服务器进程（如
www-data,nginx,apache）会拥有对/var/www/下特定子目录的读取（或读写）权限，代码文件本身的所有者可以是部署用户（如deploy），通过组权限分配给Web服务器用户，实现安全隔离（Web用户不应直接拥有代码文件的写权限）。
- Linux FHS 标准：
- 典型结构示例:
/var/www/ ├── yourdomain.com/ # 主站点根目录 │ ├── public_html/ # 实际Web可访问的根目录 (DocumentRoot) │ │ ├── index.php │ │ ├── css/ │ │ └── ... │ ├── logs/ # 应用日志 (可由Web服务器写入) │ ├── .env # 环境配置文件 (严格权限控制!) │ └── ... # 其他应用文件、配置等 └── api.yourdomain.com/ # 另一个应用或API服务 - 最佳实践:
- 为每个站点或应用创建独立的子目录。
- 严格限制
public_html/目录外的文件和目录的访问权限，尤其是配置文件（如.env）必须仅限必要用户读取。 - Web服务器用户通常只对
public_html/和logs/有读写权限（后者主要用于日志写入）,对代码库本身应只有读权限。
通用服务数据 – /srv/ (更广泛的适用性)
- 依据与优势:
- Linux FHS 标准：
/srv目录专门用于存放“此系统提供的服务特定数据”（Data for services provided by this system），这比/var/www的适用范围更广，不仅限于Web应用，也适用于API服务、后台守护进程、自定义服务等的代码和数据。 - 语义清晰： 使用
/srv明确表达了该目录下存放的是服务器提供的服务的核心数据（包括代码）,语义上非常精准。 - 良好的隔离性： 类似于
/var/www，可以为每个服务在/srv下创建独立的子目录,清晰隔离不同服务的资产。
- Linux FHS 标准：
- 典型结构示例:
/srv/ ├── http/ # 替代 /var/www 存放Web应用 │ └── yourdomain.com/ │ ├── public_html/ │ └── ... ├── api-service/ # 独立的API服务代码 │ ├── src/ │ ├── config/ │ └── ... └── data-processor/ # 另一个后台数据处理服务 - 最佳实践:
- 在
/srv下按服务类型（如http,ftp,git）或直接按服务名称创建子目录。 - 权限管理原则与
/var/www相同：服务运行用户（如api-user）拥有必要的读写权限（通常限制在特定子目录）,代码由部署用户管理。
- 在
自定义目录与容器化部署 (现代、灵活选择)
- 场景与优势:
- 自定义目录 (如
/app/,/opt/):- 高度定制化： 当您需要完全掌控环境，或者现有标准目录不满足复杂项目结构（如微服务）时，可以在根目录下创建自定义目录，如
/app/,这提供了最大的灵活性。 - 隔离性：
/opt/目录传统上用于安装“附加应用程序包”（Add-on application software packages），将整个自包含的应用（包括其代码、依赖）放在/opt/app-name/下也是一种符合标准且隔离性好的做法,尤其适合二进制分发或复杂应用。
- 高度定制化： 当您需要完全掌控环境，或者现有标准目录不满足复杂项目结构（如微服务）时，可以在根目录下创建自定义目录，如
- 容器化部署 (Docker/Kubernetes):
- 终极隔离： 容器技术将应用代码、运行时环境和依赖完全打包,代码通常作为容器镜像的一部分。
- 主机目录映射： 容器运行时，可以将主机上的任意目录（如
/home/deploy/apps/app-name/,/data/apps/app-name/, 甚至/var/lib/docker/volumes/管理的卷）映射到容器内部的工作目录（如/usr/src/app），这时，主机上的目录选择更多基于运维策略（备份便利性、存储类型、性能）而非严格遵循FHS，但/srv或/opt仍是映射主机侧代码卷的合理位置。
- 自定义目录 (如
- 最佳实践:
- 自定义目录： 确保目录权限设置严格，避免放在用户主目录（
/home/username/）下，除非是严格的开发环境，建立清晰的命名规范（如/app/service-a/,/app/service-b/）。 - 容器化： 利用Dockerfile的
WORKDIR定义容器内工作目录，在主机上，选择一个有足够空间、便于备份、符合您基础设施管理规范的目录存放持久化数据卷或用于映射的代码目录,避免将敏感数据直接暴露在映射目录中。
- 自定义目录： 确保目录权限设置严格，避免放在用户主目录（
绝对避免的目录
/home/username/(用户主目录):- 安全风险高： 用户主目录权限通常较宽松，容易导致未授权访问,Web服务器进程通常不应有访问用户主目录的权限。
- 不符合标准： 主目录用于个人用户文件,而非系统服务数据。
- 可维护性差： 与特定用户绑定,不利于自动化部署和用户切换。
/tmp/(临时文件):- 易失性：
/tmp下的文件在系统重启后通常会被清除。 - 安全性： 所有用户通常都可读写
/tmp,存在严重的安全隐患。
- 易失性：
- 根目录 () 或随意位置： 缺乏组织性，难以管理，不符合规范,容易引发冲突和安全问题。
选择目录的核心考量因素
- 服务类型 (Web/API/后台服务)： 首选
/var/www(Web) 或/srv(通用服务)。 - 遵循标准 (FHS)：
/var/www,/srv,/opt是符合标准的首选,提高可维护性和协作性。 - 安全性： 目录位置必须便于实施严格的权限控制（最小权限原则），隔离运行用户和部署用户,避免敏感区域。
- 部署方式：
- 传统/脚本部署：
/var/www,/srv是主流。 - 容器化部署： 主机目录选择更灵活（如
/srv/app-name,/opt/app-name, 专用数据卷目录）,重点在于与容器的映射和主机侧的权限管理。
- 传统/脚本部署：
- 可维护性与清晰度： 目录结构应清晰反映服务架构（一个服务/站点一个子目录），方便管理员、自动化工具理解和操作。
- 备份与恢复： 选择易于纳入备份策略的目录（如
/var/www,/srv,/app等）,确保代码和关键数据得到保护。
总结与关键建议
- Web应用：
/var/www/your-site/是最直接、最标准、支持最广泛的选择，将公开访问的文件放在public_html/或类似子目录下。 - 通用服务 (API, 后台程序)：
/srv/service-name/是最符合标准语义的选择,推荐使用。 - 追求高度定制化或复杂应用：
/app/或/opt/app-name/是可行的自定义方案,确保权限和结构管理到位。 - 容器化环境： 关注容器内工作目录 (
WORKDIR)，主机侧映射目录选择/srv/,/opt/或专用数据卷目录,并严格管理主机侧权限。 - 核心原则： 无论选择哪个目录，严格的文件权限控制（用户/组/权限位）、清晰的目录结构和纳入备份策略是保障安全、稳定和可维护性的基石，永远避免将生产代码放在
/home,/tmp或根目录下。
您当前的生产环境代码部署在哪个目录结构下？是基于 /var/www、/srv 的经典路线，还是采用了 /app 的自定义方案，或是已经完全拥抱了容器化的部署方式？欢迎在评论区分享您的实践经验和选择背后的考量！
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/6020.html
