PHP启动报“VCRUNTIME140.dll”等缺失错误，需安装对应架构的微软VC运行库；扩展加载失败多因依赖DLL未就位或架构不匹配；Apache环境变量需显式设置PATH；Composer异常常源于cURL/SSL扩展未正确加载。
php.exe 启动报错“找不到 VCRUNTIME140.dll”或“MSVCP140.dll”
这是 Windows 下 PHP 环境最常遇到的 DLL 缺失问题，本质是 PHP 二进制包依赖 Visual C++ 2015–2022 运行库，而系统没装或版本不匹配。
不要下载单个 DLL 文件手动丢进 system32 或 PHP 目录——这极易引发版本冲突或权限问题，且下次更新 PHP 就失效。
- 直接去微软官网下载安装
vc_redist.x64.exe（64位 PHP）或vc_redist.x86.exe（32位 PHP），对应你的 PHP 架构（用php -v看到的 “x64” 或 “x86” 字样） - 安装时勾选“为所有用户安装”，避免权限隔离导致 CLI 和 Web 服务（如 Apache）行为不一致
- 安装后重启命令行终端，再运行
php -v验证；若仍报错，用depends.exe（Dependency Walker）打开php.exe查看具体缺哪个 DLL，再针对性补装对应 vc_redist 版本
PHP 加载扩展时报“动态链接库初始化失败”或“The specified module could not be found”
这类错误表面是扩展加载失败，但根源往往是扩展 DLL 本身依赖的其他 DLL 没就位，比如 php_curl.dll 依赖 libssh2.dll、ssleay32.dll 等，而这些文件未放在 PHP 能搜索到的路径里。
- 确认扩展 DLL 所在目录（通常是
ext/）已加入PATH环境变量，或更稳妥地：把扩展依赖的全部 DLL（如libssh2.dll、nghttp2.dll）复制到php.exe同级目录（即 PHP 安装根目录） - 用
dumpbin /dependents php_curl.dll（需 VS 开发工具）或Dependencies.exe工具查看该扩展真实依赖链，别只凭名字猜测 - 注意扩展 DLL 的架构必须与 PHP 主程序严格一致：x64 PHP 只能加载 x64 扩展，混用必失败，且错误提示往往不明确
Apache + PHP 时出现“PHP Startup: Unable to load dynamic library”但文件明明存在
这个错误不是文件路径错了，而是 Apache 子进程继承的环境变量和你命令行不同，尤其 PATH 不包含 PHP 的 DLL 依赖路径，导致加载扩展时找不到其底层依赖。
立即学习“PHP免费学习笔记（深入）”；
- 在 Apache 的
httpd.conf中显式声明依赖路径：SetEnv PATH "C:/php;C:/php/ext;C:/php/libs"
（把C:/php/libs替换为你实际存放依赖 DLL 的目录） - 不要用
LoadFile提前加载 DLL——除非你清楚依赖顺序，否则容易引发初始化顺序错误；优先靠PATH让系统自动解析 - 修改后必须完全停止 Apache 服务（
httpd -k stop），再启动，仅 reload 不会重载环境变量
用 Composer 报错“proc_open(): fork failed – Cannot allocate memory”或 SSL 相关证书错误
这类问题常被误判为网络或权限问题，实际多因 PHP 运行时缺少必要 DLL 导致底层函数（如 proc_open、curl_init）无法正常初始化。
- 检查
php.ini中是否启用了extension=php_openssl.dll和extension=php_curl.dll，并确认这两个扩展的依赖 DLL（如ssleay32.dll、libeay32.dll或新版libssl-3.dll）已在 PHP 目录可访问 - Composer 默认使用系统 cURL，若 PHP 自带的 cURL 扩展不可用，它会 fallback 到纯 PHP 实现，性能差且易出 SSL 错误；验证方式：运行
php -r "print_r(curl_version());"，有输出才说明 cURL 扩展真正就绪 - 内存分配失败有时是杀毒软件拦截了
php.exe创建子进程，临时禁用实时防护测试；但更常见的是php.ini中memory_limit设得太低，调高到512M再试
Dependencies.exe 打开出问题的 DLL，看红色标记项——那才是你该去补的真依赖。 
