拖拽后数据库排序未更新的四大原因：csrf token缺失致请求被拦截；前端传参格式与后端接收方式不匹配；后端未执行实际数据库更新或字段名错误；并发操作导致覆盖，需事务+行锁或case when批量更新。
拖拽后数据库排序没更新，通常不是前端没动，而是后端没接住或中间断了链路。核心问题集中在 CSRF 校验失败、数据传参丢失、排序逻辑错误、并发覆盖这四类，下面分情况说清楚。
CSRF token 缺失导致请求被拦截
Laravel 默认对所有 POST/PUT/PATCH/DELETE 请求强制校验 CSRF token。拖拽用 JS 发起 AJAX 时若没带 token，请求直接被拒绝，返回 419 或 403，根本到不了控制器。
- 确保页面 HTML 中有：
- JS 中读取并注入：用 axios.defaults.headers.common['X-CSRF-TOKEN'] 设置，或 fetch 的 headers 里手动加
- 别把 token 拼在 URL 后面，也别尝试从 cookie 里手动取——Laravel 不认那种方式
前端传的数据后端收不到
常见于 jQuery Sortable 或原生 drag-drop 场景：JS 发送的是 positions[] 或 ids[] 数组，但控制器里用 $request->positions 取值时为 null。
- 检查 AJAX 的 Content-Type：如果是
application/json，需用$request->json()->all()读；表单格式则确认字段名和数组语法是否匹配（如positions[0]vspositions[]） - 用浏览器 Network 面板看 Payload 是否真实发出，再查 Laravel 日志（
storage/logs/laravel.log）确认有没有收到请求 - 控制器开头加
Log::info($request->all());直接验证原始输入
后端更新逻辑跳过了实际写库
拿到 ID 列表后，如果只做了数组重排却忘了调用 update()，或者用了错误的字段名（比如写成 order 而数据库是 sort_order），自然不会生效。
- 推荐做法：接收纯 ID 数组（如
['12', '8', '15']），循环执行DB::table('items')->where('id', $id)->update(['sort_order' => $index + 1]) - 避免信任前端传来的排序值（如
{id: 12, sort_order: 3}），防止重复、空缺或越界 - 若用 spatie/laravel-sortable，注意它适合单节点移动（
moveBefore()），不适用于整列重排
多个用户同时操作造成覆盖
两人几乎同时拖拽并保存，A 先读数据、B 后读数据，然后 A 和 B 都按自己看到的顺序写入，后写的会覆盖先写的，最终顺序和任一前端都不一致。
- 必须包裹事务：
DB::transaction(function () { ... }); - 关键更新前加行锁：
DB::table('items')->where('id', $id)->lockForUpdate()->first() - 更稳妥的方式是用单条 SQL 的
CASE WHEN批量更新，避免“读-算-写”三步法
