/srv目录专用于存放本系统对外提供服务所依赖的、由用户主动创建并维护的核心业务数据，如网站文件、ftp资源、git裸仓库等，不存日志、数据库文件、个人代码或临时缓存。
/srv目录存放的是本系统对外提供服务时所依赖的、由用户主动创建并维护的核心业务数据。它不是系统自动生成的运行产物，也不是个人文件，而是服务本身“赖以生存的原材料和成品”。
/srv存什么：典型业务数据类型
这些数据直接支撑服务对外运作，具有明确的服务归属和业务含义：
- 网站内容：HTML页面、CSS样式表、JavaScript脚本、用户上传的图片/视频（如/srv/http/example.com/public_html/）
- FTP共享资源：供外部下载或上传的文件集合（如/srv/ftp/incoming/、/srv/ftp/pub/）
- Git裸仓库：用于代码托管的.git目录（如/srv/git/project.git/）
- API服务静态资产：OpenAPI文档、示例数据集、前端构建产物（如/srv/api/docs/、/srv/api/dist/）
- 定制化服务数据：比如监控平台的仪表板配置、CI/CD流水线的模板库、内部知识库的Markdown源文件
/srv不存什么：关键边界要划清
混淆存放位置是运维事故的常见源头。以下几类数据不应放入/srv：
- 日志文件：属于系统运行时动态生成，应归入/var/log/（即使由Web服务产生）
- 数据库文件：MySQL、PostgreSQL等自身管理的数据文件，标准路径是/var/lib/mysql/、/var/lib/postgresql/
- 用户个人项目代码：开发者本地开发的源码、测试脚本，属于个人工作流，应放在/home/username/src/
- 临时缓存或会话数据：如Nginx的proxy_cache、PHP的opcache文件，应放在/var/cache/或/tmp/
- 服务二进制程序或配置文件：可执行文件在/usr/bin/或/opt/，主配置在/etc/，/srv只管“服务吃进去和吐出来的数据”
/srv目录结构怎么组织才合理
核心原则是按“服务实例”而非“技术类型”分层，便于隔离、迁移和权限控制：
- 一级子目录用服务名标识，如/srv/blog/、/srv/intranet/、/srv/backups/
- 每个服务目录内再按用途细分，常见模式：public_html/（可公开访问）、private/（仅服务进程可读）、uploads/（用户写入区）、config/（服务专用配置，非全局/etc）
- 避免跨服务混放，例如不要把博客的图片和内部系统的报表模板都塞进/srv/www/
- 若单个服务数据量大（如TB级媒体库），建议单独挂载磁盘到对应子目录（如mount /dev/sdb1 /srv/media）
为什么坚持用/srv而不是/var/www或/home
这不是教条，而是为长期维护埋下的伏笔：
- 语义清晰：看到/srv/，就知道这是“服务交付物”；看到/var/，就默认是“系统运行痕迹”；看到/home/，就明白是“某人的私人空间”
- 权限解耦：Web服务用户（如www-data）只需对/srv/http/site/有读取权，无需碰触/home或/etc，最小权限原则自然落地
- 备份精准：整站迁移时，只需打包/srv/http/site/ + 对应的/etc/nginx/sites-available/site.conf，干净利落
- 发行版友好：Debian/Ubuntu、RHEL/CentOS、Arch等主流系统均遵循FHS，/srv是跨平台共识，不依赖Apache历史默认路径
