一个网页要查数据库，网页绕不开三件事：连上数据库、数据发一条 SQL、库查把结果吐回页面。询源听起来简单，网页但真正写起来，数据坑全在细节里。库查

先说连接。询源PHP 里最常见的网页是 mysqli_connect() 或者 PDO。我见过不少新手代码，数据直接把连接参数写死在文件顶部，库查比如 $conn = mysqli_connect("localhost",询源 "root", "123456", "test");。本地跑没问题，网页一上线就完蛋——密码泄露、数据数据库地址暴露，库查甚至有人把 root 账号直接扔生产环境。更稳的做法是用配置文件加环境变量，至少别让密码出现在版本控制里。PDO 的好处是支持预处理语句，后面会说到。

连接建好之后，查数据无非是拼 SQL。但拼 SQL 这件事，几乎就是安全漏洞的温床。举个例子，一个搜索框，用户输入“手机”，你后台写 SELECT * FROM products WHERE name LIKE '%$_GET[keyword]%'。用户正常输入没事，但如果他输入 ' OR 1=1 --，整张表就被拖走了。这不是危言耸听，早些年大量网站栽在这上面。预处理语句能堵住这个口子：$stmt = $pdo->prepare("SELECT * FROM products WHERE name LIKE ?"); $stmt->execute(["%$keyword%"]);。参数和 SQL 结构分开传输，数据库不会把用户输入当成指令执行。

查询结果拿回来之后，别急着 echo。我见过一个页面，从数据库读出用户昵称直接输出到 HTML，结果有人把昵称改成 <script>alert(1)</script>，所有访问那个页面的用户都中招。这是 XSS，和 SQL 注入是两码事。防它很简单：输出前用 htmlspecialchars() 转义。别偷懒，每个从数据库出来的字段都过一遍。

分页是另一个高频场景。很多人写 SELECT * FROM articles LIMIT 10 OFFSET 20，数据量小的时候没问题。但当表里有几百万行，OFFSET 越大越慢，因为数据库得先扫过前面所有行再丢弃。我自己的习惯是用游标分页——记住上一页最后一条的 ID，下一页查 WHERE id < last_id ORDER BY id DESC LIMIT 10。速度稳定，不会随页码增长而变慢。

还有一点容易被忽略：错误处理。开发阶段把 mysqli_error() 直接打印到页面上，方便调试，但上线后这就是信息泄露。攻击者看到“Table 'users' doesn't exist”就知道你的表名了。生产环境应该把错误写日志，页面上只显示“查询失败，请稍后重试”。PDO 的异常模式可以统一捕获，try...catch 包住查询逻辑，出错就记日志、返回友好提示。

最后说一个我踩过的坑：字符集。数据库、连接、页面三处的编码必须一致，否则中文会变成问号或者乱码。MySQL 里建库时指定 utf8mb4，连接时执行 SET NAMES utf8mb4，HTML 里 <meta charset="utf-8">。少一个环节，用户提交的中文评论就可能存成乱码，回头查出来全是问号，排查半天才发现是连接层没设字符集。

网页查数据库这件事，写通很容易，写对很难。预处理、转义、分页策略、错误处理、字符集，每一项都是实战里被坑出来的经验。代码能跑只是起点，能扛住恶意输入和真实数据量，才算及格。