用户偏好存储位置有三种：浏览器端（localStorage/cookie）、服务端数据库、临时$_SESSION；前端存轻量设置，后端数据库存影响权限等关键设置，JSON类型字段更灵活。
用户设置存在哪几种常见存储位置
浏览器端存 localStorage 或 cookie 最快，但不可信、易被清空、不跨设备；服务端存数据库最稳，适合账号绑定的偏好（比如主题色、默认排序）；临时存 $_SESSION 也行，但重启会丢，且依赖 session 生命周期。别一上来就往数据库写——轻量设置（如折叠侧边栏、表格列宽）用前端存更合理；涉及权限、默认语言、通知开关这类影响后端行为的，必须落库。
- 数据库字段建议用
JSON类型（MySQL 5.7+ / PostgreSQL），或单字段序列化成字符串（json_encode()存，json_decode()取） - 避免为每个偏好建单独字段，后期加个“夜间模式开关”就得改表结构
-
$_COOKIE只适合极小量、无敏感信息的设置（如theme=dark），且要设httponly=false才能被 JS 读写
PHP 读写用户偏好时怎么避免覆盖冲突
用户同时在两个标签页操作，A 页改了主题，B 页改了字体大小，直接 UPDATE 全量覆盖会丢掉另一个改动。正确做法是只更新变动字段：
- 用
json_decode($user->settings, true)转成数组，array_merge_recursive()合并新旧值（注意深层合并需自定义逻辑） - 或改用数据库的 JSON 函数：MySQL 用
JSON_SET()，PostgreSQL 用jsonb_set()，只改指定路径 - 写入前加乐观锁：查出当前
updated_at，UPDATE 时带上WHERE updated_at = ?，失败则重试读取再合并
前端传设置给 PHP 时容易漏掉的校验点
$_POST['settings'] 看似是个 JSON 字符串，但可能被篡改、超长、嵌套过深，甚至带 PHP 对象反序列化风险：
- 必须用
json_decode($_POST['settings'], true)并检查json_last_error() === JSON_ERROR_NONE - 限制顶层键名：只允许
['theme', 'language', 'notifications', 'table_columns']这类白名单字段 - 数值类字段（如
font_size）强制转成(int)，字符串类用trim()+mb_substr($v, 0, 64)截断 - 别直接
json_encode($_POST['settings'])存——如果前端传的是已编码字符串，会变成双重编码
PHP 里怎么安全地把偏好注入到 HTML 页面
别用 echo json_encode($settings) 拼进 <script></script> 标签——XSS 风险极高，尤其当设置里含用户输入内容（如自定义标题）。正确方式是：
立即学习“PHP免费学习笔记（深入）”；
- 在响应头加
Content-Security-Policy: script-src 'self'，堵住内联脚本执行 - 用
json_encode($settings, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)编码，再塞进<script type="application/json" id="user-settings">标签 - 前端用
document.getElementById('user-settings').textContent读取，再JSON.parse() - 如果必须内联 JS，确保所有变量都经过
htmlspecialchars()处理，且不拼接进eval、setTimeout或事件处理器
用户偏好这事，表面是存几个键值，实际卡点全在边界：前端传什么、后端信多少、并发怎么保一致、错误时是否静默降级。最常出问题的不是代码写错，而是默认把 $_POST 当可信输入，或者觉得“就几个设置而已”跳过字段白名单。
