Research: Table QR Code

1. QR Code Generation Library

Decision: Google ZXing 3.5.2

Rationale:

Java 生态最成熟的二维码库
项目基于 Spring Boot，ZXing 有良好的集成支持
支持自定义二维码尺寸、颜色、logo
轻量级，无需外部服务

Alternatives considered:

QR Server API（外部服务，依赖网络，不适合生产环境）
Apache PDFBox（主要处理 PDF，二维码支持弱）
前端生成（增加前端复杂度，且二维码需要后端持久化）

2. QR Code Content Format

Decision: 使用 URL 格式 {baseUrl}/scan?type={type}&storeId={storeId}&tableId={tableId}

Rationale:

通用二维码扫描器都能直接识别 URL 并跳转
参数清晰，易于调试
前端可以根据参数直接路由到对应页面

Alternatives considered:

JSON 格式（需要专用扫码器，通用性差）
短链 + 服务端映射（增加复杂度，需要额外的映射表）

3. QR Code Storage

Decision: 后端动态生成，不存储图片文件。qr_code 字段存储二维码文本内容（URL），图片在请求时动态生成。

Rationale:

减少文件存储依赖
二维码内容可能随 baseUrl 变化，动态生成更灵活
二维码生成速度快（<10ms），无需缓存

Alternatives considered:

生成图片存文件系统（增加文件管理复杂度）
生成图片存 OSS（需要 OSS 配置，过度设计）

4. Permission Model

Decision: 在 Service 层通过 user_type 判断权限，Controller 层通过 JwtUtil 获取用户信息。

Rationale:

遵循现有项目模式（StallController 使用相同方式）
user_type 已有明确定义：3=夜市用户, 4=摊主
无需引入新的权限框架

Alternatives considered:

Spring Security 注解（项目未使用此模式）
自定义注解鉴权（增加复杂度，现有模式已足够）

5. Frontend QR Code Display

Decision: 后端返回二维码图片的 Base64 编码，前端直接在 img 标签中展示。

Rationale:

无需文件上传/下载流程
前端展示简单直接
支持下载功能（通过 a 标签 download 属性）

Alternatives considered:

返回图片 URL（需要文件存储）
前端自己生成二维码（需要额外依赖，且参数来自后端）

6. Night Market ID 获取方式

Decision: 摊主的 night_market_id 从关联的 PosStore 记录获取；夜市管理员的 night_market_id 从 InfoUser 表获取。

Rationale:

PosStore 表已有 night_market_id 字段
InfoUser 表中夜市用户（type=3）的地址信息关联夜市
遵循现有数据关系

7. Entity Pattern

Decision: 遵循 PosStore 的实体模式，使用 MyBatis Plus 注解（@TableName, @TableId）+ Lombok（@Data）。

Rationale: 项目所有实体都遵循此模式，保持一致性。