用枚举 SeatStatus 存座位状态更安全，避免魔法数字；连座校验需检查边界、不可用座及并发抢占，不能仅查连续索引。
二维数组怎么存座位状态才不翻车
用 int[][] 或 boolean[][] 存座位最直接，但别一上来就写 new int[10][20] 然后默认 0=空、1=已售——实际卖票时你得区分“可售”“已锁”“已售”“不可用（过道/设备位）”，光两个状态根本不够。
-
0表示可售（用户能点） -
1表示已售（不可操作） -
-1表示不可用（比如消防通道旁的固定空位，不能选也不能卖） - 加个临时状态
2表示“已预占但未支付”，5分钟自动回滚
Java/C# 里建议封装成枚举 SeatStatus，Python 可用 Enum，避免散落一堆魔法数字。不然改个状态逻辑，全项目搜 == 1 都不敢动。
选座时怎么批量校验连坐合法性
用户要买 3 张连座，不能只检查 seats[row][col]、seats[row][col+1]、seats[row][col+2] 就完事——漏了边界越界、中间夹着 -1（不可用座）、或有人刚抢走中间那个。
- 必须先用
col + count 检查列范围，否则 <code>ArrayIndexOutOfBoundsException - 遍历区间内每个
seats[row][j]，遇到!= 0就立刻失败（包括-1和1） - 校验通过后，不是直接改数组，而是用原子操作（如
compareAndSet或数据库行锁）更新状态，防并发超卖
常见错误：前端传过来的 row 是从 1 开始编号，后端数组下标从 0 开始，忘了 -1 就越界；或者没校验是否跨排（用户选了最后一列+下一排第一列，误判成连座）。
为什么不能在内存里一直 hold 着整个二维数组
一个 IMAX 厅 20×30 座位才 600 个元素，看似很小，但 100 个厅同时在线？内存里存 100 个 boolean[20][30] 没问题；但加上锁状态、用户 ID、锁定时间戳、支付倒计时……对象膨胀很快。更麻烦的是重启丢数据、多实例不同步。
- 内存只缓存「最近活跃厅」的座位快照，其余厅状态从 Redis 或 DB 按需加载
- 每次选座成功后，必须同步更新持久层，不能只改内存数组
- Redis 推荐用
HASH存每厅：HSET seat:hall_7 row_5 "0,0,1,0,-1,0"，按行存字符串比嵌套结构序列化更省空间、更新粒度更细
性能陷阱：有人图省事把整张二维数组 JSON.stringify() 存进一个 DB 字段，查连座就得全取出来解析——单次查询从 O(1) 变成 O(n)，还锁表。
前端传来的座位坐标怎么防刷和错位
别信前端传来的 row 和 col，它们可能被手动篡改、越界、或对应不到真实物理座位（比如某厅第 3 排实际只有 18 座，但前端渲染了 20 个格子）。
- 后端必须查配置表确认该厅的
rows和cols，再做row 校验 - 物理座位号（如 “B12”）和数组下标是两套体系，转换逻辑必须收口在统一函数里，例如
parseSeatCode("B12") → {row: 1, col: 11} - 加一层简单限频：同一 IP/用户 5 秒内超过 3 次选座失败，临时拒绝，防脚本暴力扫座
容易被忽略的点：无障碍座位通常分散在不同排，但逻辑上要标记为“不可连座”，即使相邻也得单独校验——这个规则不会体现在二维数组里，得额外查座位属性表。
