技术博客
PHPWAF 没有“高/中/低”三档按钮式防护等级，它的“强度”由三部分共同决定：php_waf.mode（检测模式）、php_waf.rule_path（加载哪些规则文件）、以及每条规则的 action（是记录、警告还是直接 deny）。很多人误以为改个 mode=strict 就万事大吉，结果发现拦截不准或漏报严重——问题往往出在规则没跟上，或动作没对齐。
Dreamweaver（DW）本身不执行 PHP，它只是代码编辑器，所有 PHP 调试信息必须在真实 Web 服务器环境（如本地 XAMPP、MAMP 或远程环境）中运行后，通过浏览器或服务器日志查看。直接在 DW 界面点“实时视图”或“在浏览器中预览”时，若没配好本地服务器，echo、var_dump 都不会显示——这是最常被误以为“DW 不支持 PHP 调试”的根源。
默认值通常是 30 秒，超过这个时间 PHP 就会中止脚本并报错 Fatal error: Maximum execution time of X seconds exceeded。这个限制在 CLI 模式下默认为 0（不限时），但在 Web 服务器（如 Apache、Nginx）环境下由 PHP 配置决定，和 Dreamweaver（DW）本身无关——DW 只是编辑器，不运行 PHP。
Composer 不是“装进 XAMPP”，而是靠命令行调用 XAMPP 自带的 php.exe。如果这一步没通，后面全卡住。
当您在PHP应用程序中发现潜在的安全漏洞时，应立即启动应急响应流程以遏制风险扩散。以下是发现PHP漏洞后必须执行的几个关键操作：
PHPWAF 是以 PHP 扩展形式加载的（如 phpwaf.so），没有独立进程，因此不能用 systemctl stop phpwaf 这类命令。它的启停完全依赖于 PHP 配置是否启用该扩展。
因为容器是隔离环境，宿主机的 composer 命令对容器内完全不可见。你执行 docker run -it php:8.2-cli composer –version 会报错 command not found —— 这不是路径没配对，是根本没装。
用户提交的文件名（比如通过表单、URL参数）如果直接拼进 fopen() 或 file_put_contents()，就等于把目录穿越的钥匙交出去。攻击者传 ../../etc/passwd 这类路径，PHP 不会自动拦截——它照常解析、访问、写入。
数据库调用型后门不直接执行system或eval，而是借合法数据库操作（如mysqli_query、PDO::query）动态拼接并执行恶意SQL，因此常规关键字扫描容易漏掉。
Composer 在 WAMP/XAMPP 环境下无法直接运行，根本原因不是环境不支持，而是 PHP 命令行（CLI）版本与 Apache 使用的 PHP 版本不一致，且 PATH 未正确配置 —— 这导致 composer 命令找不到可用的 PHP 解释器。