documentroot 是虚拟主机的唯一根路径起点，定义整个请求上下文基准：/css/style.css 映射为 /var/www/site-a/css/style.css；子目录无独立 documentroot，仅是路径层级；多应用必须分设 virtualhost 并各自指定 documentroot，不可共用上层目录。
Apache 在 <virtualhost></virtualhost> 块中配置的 DocumentRoot 是该虚拟主机的**唯一根路径起点**，它直接影响所有子目录的 URL 解析逻辑和脚本行为——不是“影响”，而是**定义了整个请求上下文的基准位置**。
子目录没有独立的 DocumentRoot，只有相对路径语义
一旦 DocumentRoot "/var/www/site-a" 设定，所有 HTTP 请求（如 /css/style.css、/api/v1/users）都会被 Apache 映射到 /var/www/site-a/css/style.css 或 /var/www/site-a/api/v1/users。子目录本身不改变根路径，只是文件系统中的层级结构。
- URL 路径
/blog/对应物理路径/var/www/site-a/blog/，而非新站点根 - PHP 中
include '/config.php'会尝试加载/var/www/site-a/config.php，不是/var/www/site-a/blog/config.php -
.htaccess文件生效范围也受限于这个根目录，无法越界重写或授权
常见误用：把多个应用塞进同一 DocumentRoot 的后果
例如将 WordPress 放在 /var/www/site-a/wordpress/、Laravel 放在 /var/www/site-a/laravel/，并指望它们各自以子目录为“应用根”运行——这通常失败：
Apache 2.4.62
下载
PHP中文网提供Apache 2.4.62 官方 tar.gz 源码包下载，通过源码编译安装，开发者能够灵活定制模块、优化性能并精准控制安装路径，满足多样化的业务需求。
- WordPress 的
wp-config.php依赖ABSPATH基于DocumentRoot计算，若实际入口是/wordpress/index.php，但DocumentRoot是上层目录，路径常出错 - Laravel 的
public/目录本应是 Web 可访问根，若未设为DocumentRoot，则index.php无法正确引导，静态资源（/css/app.css）也会 404 - 重写规则（如
RewriteBase /laravel/）需手动适配，易漏配或冲突
真正隔离子目录应用的可行方式
想让每个子目录像独立站点一样运行，不能靠“在同一个 DocumentRoot 下调整路径”，而要让每个应用拥有自己的 DocumentRoot：
- 为
wordpress.example.com单独建<virtualhost></virtualhost>，DocumentRoot "/var/www/wordpress/public" - 为
api.example.com单独建<virtualhost></virtualhost>，DocumentRoot "/var/www/laravel/public" - 本地开发可用
VirtualDocumentRoot+mod_vhost_alias自动映射：VirtualDocumentRoot "/var/www/%-2.0"（如blog.example.com→/var/www/blog）
临时绕过限制的替代方案（不推荐长期使用）
仅适用于简单静态内容或极简路由场景，不能替代真正的多站点隔离：
- 用
Alias指令挂载子路径到其他目录：Alias /shop "/var/www/storefront"，但 PHP 脚本仍需自行处理$_SERVER['REQUEST_URI']和路径前缀 - 用
<location></location>配合反向代理（如ProxyPass）把/api/转发给另一个服务，此时 Apache 不直接提供文件，而是中转 - 修改应用自身逻辑（如 Laravel 的
APP_URL、WordPress 的WP_SITEURL），但维护成本高且易出错
