做网站的时候，谁还没遇到过报错？但你有没有想过，那些弹出来的错误提示，可能正悄悄暴露服务器路径、数据库账号，甚至代码结构？
错误信息不该是黑客的说明书
想象一下：用户登录失败，页面直接显示“MySQL 连接错误，用户名 root，密码为空”。这等于把家门钥匙挂在门口。很多开发者习惯性开启详细错误提示，方便自己调试，却忘了上线后这些信息对攻击者来说就是宝藏。
比如一个常见的 PHP 错误：
<?php echo file_get_contents("/etc/passwd"); ?>如果服务器配置不当，浏览器可能直接爆出完整路径：Warning: file_get_contents(/var/www/html/config.php): failed to open stream...。攻击者立刻知道文件结构，下一步就是尝试读取配置文件。
生产环境要“装傻”
上线前一定要关掉详细错误显示。以 PHP 为例，在 php.ini 中设置：
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log错误只记录到日志，不展示给用户。用户看到的应该是统一的友好提示，比如“系统繁忙，请稍后再试”。
Node.js 项目也一样。别在响应里直接 throw 出 err.stack。用中间件捕获异常：
app.use((err, req, res, next) => {
console.error(err.stack);
res.status(500).send('Something went wrong!');
});自定义错误页面更安全
404、500 这类状态码不可避免，但可以控制返回内容。Apache 可通过 .htaccess 设置：
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-error.html这些页面不透露技术细节，也不暴露目录结构。哪怕是空白页，也比默认的错误堆栈强。
现代前端框架如 React 或 Vue，也能在路由层拦截错误，显示预设提示，避免白屏或控制台信息外泄。
日志也要管住
错误藏起来不等于完事。日志得保存，但不能放在 web 可访问目录。比如把日志存到 /var/log/app/，而不是 /public/logs/。否则一个意外的目录遍历漏洞，就能让黑客下载全部日志。
定期检查日志权限，确保只有运维人员能查看。敏感字段如密码、身份证号，记录时要做脱敏处理。
安全不是加个验证码就完事。从一行错误提示开始，守住底线，才能让应用更经得起考验。