htmlspecialchars接收非字符串参数会报错，因php 8.1+严格校验类型；常见于$_post未定义字段、数据库null值或变量被覆盖为数组；应使用$value ?? ''前置兜底并显式指定ent_quotes与utf-8编码。
htmlspecialchars 接收了非字符串类型参数
这个错误说明你传给 htmlspecialchars() 的值不是字符串，比如是 null、array、int 或对象。PHP 8.1+ 开始严格校验类型，不再自动转换，直接报错。
常见场景：从数组取值（如 $_POST['name']）未定义时返回 null；数据库查询结果某字段为 NULL；或变量被意外覆盖为数组。
- 用
is_string()或is_scalar()做前置判断，非字符串则转成空字符串或跳过处理 - 更稳妥的做法是统一 cast：
(string)$value，但注意数组转字符串会变成"Array"，不推荐用于调试以外的场景 - 对可能为
null的值，优先用空合并操作符：htmlspecialchars($value ?? '', ENT_QUOTES, 'UTF-8')
$_POST / $_GET 中的字段未设置就直接 htmlspecialchars
表单未提交、字段名拼写错误、或前端未发送该字段时，$_POST['xxx'] 是未定义的，读取即为 null，直接传给 htmlspecialchars() 就触发错误。
- 永远不要裸写
htmlspecialchars($_POST['username']) - 改用
$_POST['username'] ?? ''或filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING) ?? ''（注意：PHP 8.1+ 已弃用FILTER_SANITIZE_STRING） - 如果用了框架（如 Laravel），优先走 request validation 和
old()辅助函数，它们天然处理缺失值
数据库查询结果含 NULL 字段，没做空值处理
MySQL 中某列为 NULL，PDO 或 mysqli 返回后仍是 null，直接丢进 htmlspecialchars() 就崩。
- 查询时用
COALESCE(name, '')在 SQL 层兜底 - PHP 层用三元或空合并：
htmlspecialchars($row['name'] ?? '', ENT_QUOTES, 'UTF-8') - 避免用
isset($row['name']) ? htmlspecialchars($row['name']) : ''，因为isset(null)为 false，但$row['name'] === null时仍需处理，??更简洁安全
ENT_QUOTES 和字符编码参数漏传或错传
虽然这不是导致“expects parameter to be string”错误的直接原因，但常和它一起出现——比如你试图修复类型问题，随手加了个 htmlspecialchars($val, ENT_QUOTES)，却忘了第三个参数 $encoding，而 PHP 默认用 ini_get('default_charset')，若配置为空或非法，会触发其他警告，干扰排查。
- 始终显式指定编码：
htmlspecialchars($value ?? '', ENT_QUOTES, 'UTF-8') -
ENT_QUOTES是安全首选，它同时转义单引号和双引号，防止属性注入 - 别依赖默认值，尤其在多环境部署时，
default_charset可能不一致
最易被忽略的是嵌套结构：比如 $data['user']['profile']['bio'] 某层为 null，但只判了顶层，深层访问仍出错。遇到深层字段，要么用 nullsafe 操作符（PHP 8.0+：$data?->user?->profile?->bio ?? ''），要么封装一个安全获取函数。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
