硬编码密码是部署配置问题而非workerman缺陷，须通过环境变量注入敏感信息、严格隔离配置目录、禁用危险函数并启动时校验密码。
硬编码密码不是Workerman的问题，而是部署和配置习惯问题。只要密码出现在代码里（比如config/database.php或start.php中），就等于把钥匙贴在门上——哪怕Workerman进程本身再安全，一次误配、一次错误的Web服务器暴露、一次日志打印，都可能让密码裸奔。
把密码从代码里彻底移出去
所有敏感字段（数据库密码、Redis密码、第三方API密钥）必须剥离出PHP文件，改由运行时注入：
- 系统级环境变量最可靠：在
/etc/environment或systemd服务文件中用Environment="DB_PASSWORD=xxx"声明，PHP通过getenv('DB_PASSWORD')读取 - 避免
.env文件：它容易被Nginx/Apache误配成静态文件返回；若必须用，确保其路径不在Web根目录下，且composer.json已加入"vendor/bin/dotenv" : "ignore"规则 - 禁止在
var_dump()、print_r()或异常堆栈中打印含密码的配置数组——加一层unset($config['password'])再输出
防止配置文件被Web服务器直接解析或下载
很多泄露不是因为代码写错，而是因为目录放错了位置或Web服务器没拦住：
- 确认
config/、app/、runtime/等目录**完全不在Nginxroot或ApacheDocumentRoot范围内**；正确结构应是：/var/www/myapp/（项目根）→/var/www/myapp/public/（Web根）→ 其他目录全部在public同级但不可访问 - Nginx必须加全局拦截：
location ^~ /config/ { return 403; }、location ^~ /app/ { return 403; }，不能只靠deny all在子目录里 - 检查PHP是否禁用了
allow_url_include = Off和disable_functions = exec,shell_exec,system,passthru,proc_open，防止攻击者利用任意文件包含加载配置文件
启动阶段主动校验密码是否存在
别等上线后才发现密码没传进去——在start.php最开头就做防御性检查：
$db_password = getenv('DB_PASSWORD') ?: $_SERVER['DB_PASSWORD'] ?? null;
if (!$db_password || strlen($db_password)
- 不依赖
$_ENV——它默认不填充，需php.ini设variables_order = "EGPCS" - 对密码长度、字符集做基础校验（如至少含大小写字母+数字），防误填空值或默认值
password - CI/CD流水线中用
grep -r 'DB_PASSWORD.*=' . --include="*.php"扫描硬编码，失败即中断构建
真正危险的从来不是“会不会被黑”，而是“被黑了多久才发现”。硬编码密码的漏洞一旦存在，它不会报错、不会告警，只会安静地躺在日志里、Git历史中、备份文件里——直到某天被自动化工具扫出来。
