mysqli_query()返回true不等于执行成功，需检查affected_rows、show warnings、sql_mode及事务状态，返回false时必须用mysqli_error()获取具体错误。
MySQLi执行SQL失败，不是“没报错就成功了”，而是错误可能被静默吞掉、被警告掩盖、或根本没触发你预期的逻辑分支——得主动验证，不能只看mysqli_query()返回true。
为什么mysqli_query()返回true却没生效
常见于UPDATE/DELETE影响0行、INSERT因唯一键冲突被跳过、或字段被截断但没报错。这些情况mysqli_query()仍返回true，因为语句本身语法合法，只是执行结果不符合预期。
- 执行后立刻查
mysqli_affected_rows($conn)：UPDATE返回0不等于失败，可能条件没匹配到任何行 - 紧接着运行
SHOW WARNINGS（用mysqli_query($conn, 'SHOW WARNINGS')），检查是否有Level: Warning，比如“Data truncated for column 'name'” - 确认
sql_mode是否含STRICT_TRANS_TABLES，否则超长字符串插入会被静默截断
如何真正捕获执行层面的错误
靠mysqli_error($conn)或$conn->error，而不是只判断返回值。尤其注意：事务中出错后不ROLLBACK，数据状态会不可预测。
-
mysqli_query()返回false时，必须调用mysqli_error($conn)获取具体错误信息，例如"Duplicate entry '1' for key 'PRIMARY'" - 在事务块中，一旦
mysqli_query()返回false，立即mysqli_rollback($conn)，否则后续COMMIT会把部分变更提交出去 - 不要用
try/catch包mysqli_query()——它默认不抛异常；只有启用了mysqli_report(MYSQLI_REPORT_STRICT)才抛mysqli_sql_exception
连接失败时if (!$conn) 为什么经常失效
因为mysqli_connect()在MYSQLI_REPORT_STRICT模式下直接抛异常，根本不会返回false，导致if (!$conn)逻辑完全跳过。
- 统一用
try/catch处理连接：启用mysqli_report(MYSQLI_REPORT_STRICT)后，new mysqli()或mysqli_connect()失败会抛mysqli_sql_exception - 若不想改全局报告模式，禁用严格模式后，再用
if (!$conn) { echo mysqli_connect_error(); }兜底 - 连接失败后别直接
die()，先记录mysqli_connect_errno()和mysqli_connect_error()，方便排查是凭据错、DB名错，还是网络不通
多语句和大小写问题常被忽略
mysqli_query()不支持分号分隔的多条SQL；表名在Linux服务器上区分大小写，但代码里写错大小写就直接报Table doesn't exist。
- 创建库+建表必须拆成两次
mysqli_query()调用，或改用mysqli_multi_query()（注意它返回的是多个结果集） - 执行前先
USE database_name，避免在查询里写database.table时因DB名大小写不一致失败 - 查
SHOW VARIABLES LIKE 'lower_case_table_names'确认服务器策略；跨平台迁移后，用SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db'核对真实表名大小写
最易被绕过的点：你以为SQL执行完了，其实它只是“没报错地失败了”。验证必须落到行数、警告、事务状态、表名拼写这四个具体维度上，缺一不可。
