后台留言批量删除接口按参数拼接，删除范围该怎么校验

后台留言批量删除接口按参数拼接时，删除范围该怎么校验，答案不在前端传了哪些编号，而在服务端有没有重新算一遍范围。很多后台会把列表页勾选的多条记录连同它们的编号一起提交，接口拿到编号列表后直接拼进删除条件，看似省事，实则把判断删哪些的责任推给了调用方。前端传什么是可以被改写的，服务端如果照单全收，删除范围就失去了约束。

批量接口为什么把影响面放大

单条删除接口一次只处理一条记录，越界的后果通常局限在一条数据上。批量接口把多条记录的编号打包进同一个请求，一次误判就放大成一片。列表页勾选、全选、按筛选条件删除这些交互，天然会让一个请求携带成串的编号。编号越多，参数被篡改或被误解的空间越大：只要其中一段拼接没有约束，本该删除当前栏目的语句就可能顺带命中别的栏目、别的状态区间，甚至别人名下的数据。PbootCMS 在 V3.2.18 的更新记录里就修过这一类问题——后台留言的批量删除存在参数注入风险，修复方向是严格校验要删除的 id 列表，而不是信任前端传来的编号。这里的 id 指记录在数据库里的主键编号。

编号列表要按什么校验

校验要分两层。先校验单个编号本身：类型对不对，是不是预期里的整数主键，还是一段混着符号的字符串；格式干不干净，有没有被塞进额外的条件片段；数量在不在合理区间。PbootCMS 那个修复的核心也正是这一层，把 id 列表按类型和存在性逐条核对，非法的直接拒掉。再校验整批编号：每一个都得确认落在当前操作者有权访问的数据范围内，属于同一个栏目，属于同一状态区间，而不是混进跨栏目或跨权限的编号。存在性也要查，数据库里查不到的编号说明请求和数据对不上，应当拒绝整批或剔除后再报错，而不是拼接后交给删除语句。

删除范围为什么要服务端重新算一遍

前端传来的编号只是意图，不是授权。服务端不能拿编号当范围，而要拿当前会话的身份、权限、栏目归属去重新算出这次允许删除的集合，再和编号取交集。交集之外的编号，要么拒掉要么整批失败。这样即便有人在参数里塞进越界编号，服务端重新计算的这一步也会把它挡下来。范围校验还要求删除条件不能只靠编号列表拼接，应把归属条件一起带上，让数据库层面的过滤条件天然圈住能删的行。这里的 where 指删除语句里限定命中范围的过滤子句。

删错之后靠什么兜住

即便校验做到位，误删的风险也不能说归零：勾错、理解偏差、脚本异常都可能让范围之外的记录被删。所以删除接口需要一道兜底。常见的做法是不做物理删除，而是把记录先移入一个可恢复的位置，等确认无误再彻底清理。站内做法上，AnQiCMS 删除正式文档不是物理删除，而是移入「回收站」，删错了可从回收站恢复。这一条能力就到此为止：它兜住的是误删之后的可逆性，让一次范围判断的失误不至于立刻变成不可挽回的数据损失。

常见问题

问：批量删除只要前端已经限制了勾选范围，服务端还需要再校验吗？

答：需要。前端限制只是体验层的约束，参数在传输中可被改写，服务端必须把它当成不可信输入，重新算一遍允许删除的范围。

问：编号里混进一个非法值，是整批失败还是跳过它继续删？

答：更稳妥的是整批拒绝并报错，避免一半删除一半跳过造成状态不一致；确实要跳过的前提，是明确告知调用方哪些编号被剔除了。

问：回收站能替代范围校验吗？

答：不能。回收站兜的是删错之后的可逆性，校验挡的是删除范围越界本身，两者作用在不同阶段，缺一不可。