usestate更新房间状态需生成新数组而非修改原数组，批量操作应合并setstate，时间比较须转date对象，状态值需容错处理，后端数据须清洗校验。
房间状态更新总不生效？useState 的数组更新别直接改原数组
React 里用 useState 管理房间列表，点了“入住”按钮却看不到界面变化，大概率是直接 push / splice 了原数组。React 不会监听数组内部变化，只认引用是否变了。
正确做法是生成新数组：
setRooms(prev => prev.map(room =>
room.id === targetId ? { ...room, status: 'occupied' } : room
))
- 别写
rooms.push(...)或rooms[index].status = 'occupied' - 批量更新（比如清空全部空房）用
filter+map组合，别先splice再setState - 如果状态依赖前一个值（比如切换“已满/可订”），一定用函数式更新，避免闭包捕获旧值
筛选空闲房间时 filter 返回空数组？检查字符串比较是否带空格或大小写
后端返回的 status 字段可能是 "available"、"Available" 或带空格的 " available "，前端 filter(room => room.status === 'available') 就会漏掉。
实际业务中状态值往往不规范，得做容错处理：
- 统一转小写再比：
room.status?.toLowerCase().trim() === 'available' - 优先用枚举常量，比如定义
const STATUS = { AVAILABLE: 'available', OCCUPIED: 'occupied' }，前后端对齐 - 如果后端返回数字码（如
0表示空闲），别硬写=== '0'，注意类型——=== 0才对
预订时间冲突判断老出错？别只比 start 和 end 字符串
用户选了 2024-05-10 到 2024-05-12，系统提示“该时段已被预订”，但点开看发现另一单是 2024-05-11 到 2024-05-13 —— 这确实是冲突，但如果你只用字符串 >= 比较，就可能因为字典序错判（比如 <code>"2024-05-10" > "2024-05-2" 成立）。
- 必须转成
Date对象再比：new Date(a.start) new Date(b.start) - ISO 格式字符串（
"2024-05-10"）可直接传给Date，但带时分秒的要确认时区，建议统一转为 UTC 或后端返回时间戳 - 前端校验只是体验优化，最终以服务端校验为准——别省掉 API 层的冲突检查
多个房间批量操作后 UI 卡顿？别在循环里反复调用 setState
管理员点“全部设为维修中”，代码写了个 for 循环，每轮都 setRooms(...)，结果页面卡住、状态乱跳。
React 18 默认开启自动批处理，但仅限于事件处理器内；如果用了 setTimeout、Promise.then 或原生事件（如 addEventListener），就得手动合并：
- 把所有变更攒成一次新数组，最后调一次
setRooms - 真需要异步更新（比如等 API 返回后再改状态），用
useTransition或startTransition包裹，避免阻塞交互 - 超大房间列表（>500 条）考虑虚拟滚动，别一次性渲染全量 DOM
状态逻辑看着简单，但房间数、时间精度、并发操作一叠加，边界就特别多。最常被跳过的其实是后端返回数据的清洗——别信它字段名和值一定靠谱。
