@coollight56
1. 推荐你能改成 get 请求，就改成 get 请求，是你想要的效果的最优解。
2. 把分页参数使用父类或者泛型包装。
3.分页参数不要放在 body ，改用 param 。post 不仅能接受请求体的数据，也能接受请求的 url 上的参数，使用这方式也能将分页参数和业务参数隔离。

最后，如果 op 的公司没有说必须使用 post,这里只要换成 get 请求方式，都不需要 op 再自定义注解，就能达到 op 的要求：
@GetMapping("/schemeUserList")
public ApiResult<PageResult<?>> schemeUserList(@NotNull Long schemeId,
@Valid UserSearchParam userSearchParm,
@Valid PageParam pageParam)
// TODO
}

op 最后自定义了一个 @ComboParam ，你最终的处理不还是把请求参数封装在一个对象里面吗？
发送方以对象格式封装参数发给你，你在参数解析器里再把请求参数解析拆分后，最后又封装到了对象里，这样有什么意义？就为了把 schemeId 单独拿出来？又或者像你在 13 楼所表述的：请求发送方发送的参数包含你不需要的数据？
那解决思路不应该是再定义一个统一的前置的 Interceptor ，根据方法的入参去过滤掉请求体里不需要的数据吗？
当然，更推荐的应该是在你们的前后端交互规范里确立：前端应在不同的业务场景调用不同或者相同的接口仅传递必要的参数，而不能一窝打包交给服务端

另外，我看下来大家的回复也不是再说 json 传参符不符合规范啊？ json 本就是现在主流的数据传输类型，和规范有什么关系？

我权且不论为啥一个查询接口使用 post ，估计这也不是 op 能决定的，而是 op 公司的传统。
根据 op 补充说明，请求发送方的数据格式不还是一个对象吗，为什么接收方要修改数据格式？我还没想到有什么场景需要这样做？

@jzphx
@spritecn
@yanqiyu
@dark456852
我现在遇到的问题就是，群晖里的 6 块盘是 SHR ，那要么是一点点往新盘复制，这样可能是要拆解降级，风险太大了；要么是整体存储卷挂到飞牛，但是我的硬盘是通过 HBA 卡直通到群晖里的，这样能不能直接挂到飞牛里去

@badgv
@Co1e
@dcsuibian
@alfawei
原因还没有排查出来，我查过宕机前的群晖资源监控，CPU 、内存都没有波动且占用也都不高，CPU 常态 0-1%，内存常态 13-15%，磁盘读写也都正常。板 U 是 I3 8100t + b365m.

我的磁盘只会在存储空间做数据清理和 NFS 使用时读速很高，峰值在 1.2GB/s, NFS 写速峰值在 25MB/s

后来我就限制了 NFS 读写速度和关闭数据清理，NFS 读峰值降到了 4-500MB/s 左右。在调整之前，宕机频率很高，三五天就会挂一次，限制完后，宕机频率就低很多了，但仍然存在就还是没解决，所以我准备把 NFS 这块的需求和数据迁移出群晖，先不影响其他跑的服务，同时再排查看看问题出在哪

我看你有 4 块 16t 硬盘，大概率是要跑 pt, 或者说有文件服务的需求。那你选主板就要注意要么自身能带多 sata 口的，要么能给多条 pice 的，毕竟你要留一个给万兆网卡。然后就是建议你留点预算给电源和 ups ，这两个一定要好

@muxui 不清楚了，很久前测的了，现在用一块 HBA 带了 7 块 16T 直通群晖跑 pt, 现在电费还能接收，还留了一个 pcie 和你一样留给万兆网卡

i3 8100t + tuf b365m plus gaming ，我自用，能满足你的需求，平稳运行 pve, 就是架构比较老（系统启动就要很长时间）。