国际版答题系统Java实践：多语言、时区与并发控制全解析

做海外答题活动那阵子，我朋友跑来找我。他说公司要在App里加一个面向十几个国家的答题功能，问我能不能给套源码参考下。我第一反应是这不就出题、答题、判分三件事嘛，等真正把需求理清楚，才意识到“国际版”三个字才是整套系统的核心难点。时区、语言、题目格式、判分策略、并发提交、防止重复刷题，每一项都藏在看似简单的流程背后。

这篇博文就基于我当时整理的一套“国际版答题系统”Java源码来写，把它拆开讲清楚：从需求分析到技术选型，从题库多语言设计到答题会话状态机，从并发控制到内存问题排查，再到一堆只有在真实环境里才会踩到的坑。适合三类人看：正准备做答题类产品的后端开发，在准备笔试系统相关面试题的同学，以及想通过一个完整项目把Spring Boot、MyBatis、Redis串起来的人。我会把关键代码、表结构、接口设计都贴出来，并解释每一步为什么这么设计。

1. 为什么需要一套国际版答题系统：从需求拆解到模块规划

1.1 国际版和国内版的本质差异：不只是翻译

很多人一听“国际版”三个字，下意识觉得就是把界面文案换成英文。实际做需求调研时你会发现，差异远不止语言层面。

用户分布在不同国家，意味着时区不同。一个活动如果定在“北京时间晚上8点开始”，纽约用户可能就是早上8点，欧洲用户是下午1点。答题倒计时、活动开赛时间、排行榜的“今日榜”归零点，全部得按用户所在时区重新计算。

网络环境差异巨大。有些地区4G信号不稳定，答题过程中断网、弱网重试是常态。这就要求接口设计必须支持断点续答，前端每答一题向后端上报一次，而不是等到交卷时一次性提交全部答案。一旦用户中途断网，再回来时已答题目不能丢。

地域合规和内容审核也绕不开。不同国家对在线答题活动的要求不一样，有的地区不允许给实物奖励，有的地区对收集用户信息有严格限制。答题系统涉及用户ID、答题记录，甚至IP地址，设计时要考虑数据存储地域、日志脱敏这些偏运维的东西。我当时的做法是在代码里预留了RegionStrategy接口，后续接合规逻辑时不用改主流程。

1.2 系统核心模块划分：题目、会话、判分、排行榜

一套完整的答题系统，按业务流程可以分为五个模块：

• 题目管理：维护题库，支持单题增删改查和批量导入，处理多语言内容。
• 答题会话：从用户点击“开始答题”到“交卷”的完整状态流转，负责题目下发、答案暂存、倒计时控制。
• 判分服务：对用户提交的答案做判定，支持单选、多选、填空、判断等题型，输出得分和正确率。
• 排行榜与奖励：根据判分结果形成排名，支持按总分、用时、连续答对数等维度排序。
• 后台管理：配置活动、上下架题库、查看答题日志、导出统计报表。

模块划好之后再设计数据库表，至少需要：用户表、题目表、题目翻译表、选项表、答题会话表、答题明细表、排行榜快照表。这些表之间的关系我在后面章节展开。

2. 技术栈选型与工程骨架：Spring Boot 3 + MyBatis 如何搭出可扩展底座

2.1 为什么选这些组件：选型理由要能说得出口

这个项目我选的是Spring Boot 3.2 + MyBatis Plus 3.5 + Redis 6 + MySQL 8。这套组合在Java后端项目里算主流偏稳妥的，面试时被问到“为什么不用XX框架”，至少能说出三点理由：

Spring Boot 3.x基于Spring Framework 6，内置了GraalVM原生镜像支持，虽然实际项目我没上原生编译，但保留了后续优化的可能性。它的spring-boot-starter-validation、spring-boot-starter-data-redis等起步依赖能快速把工程骨架拉起来，需要什么功能加什么starter，不用自己拼版本号。

MyBatis Plus相较于原生MyBatis，最大价值是提供了BaseMapper和LambdaQueryWrapper，单表CRUD基本不用写XML。答题系统里题目表、选项表、会话表的操作以单表为主，复杂的多表联查只出现在后台统计报表里，这种场景用MyBatis Plus很顺手。如果项目里全是复杂的动态SQL和报表查询，那可能原生MyBatis或JPA更合适。

Redis在这里承担了三件事：答题会话状态缓存、题目列表缓存、排行榜临时计算。MySQL负责持久化，判分完成后把结果落库。关于Redis和MySQL的详细分工，在第5章展开。

2.2 工程结构设计：按业务边界分包，而不是按技术分层

Java Web项目常见的分包方式是controller、service、mapper、entity这种按技术角色划分，小项目没问题，但业务模块多了之后，改一个答题功能要同时改动四五个包，不够内聚。

这个答题系统我改成了按业务域分包：

code复制com.quiz.international
├── common           // 通用工具、异常、返回体
├── question         // 题目域：实体、Mapper、Service、Controller
├── session          // 答题会话域
├── grading          // 判分域
├── ranking          // 排行榜域
├── admin            // 后台管理域
└── config           // 全局配置

每个域内部自己组织controller、service、mapper，跨域调用通过Service接口。比如判分域要读题目，不直接查题目表，而是调用QuestionService的接口。这样做的直接好处是：后面如果要把判分拆成独立的微服务，只需要把GradingService的接口改成Feign调用，上游代码不用动。

2.3 JDK版本与构建配置：源发行版17的坑从哪来

工程基于JDK 17。选17的原因是Spring Boot 3.x要求JDK最低17，同时17是LTS版本，企业用起来比21更保守稳妥。

但这里有个高频报错，几乎每个用IDEA拉下工程的人都会遇到：java: 警告: 源发行版 17 需要目标发行版 17。原因特别简单——Maven编译插件指定的Java版本跟IDE的Project SDK不一致。

我pom.xml里的配置是这样的：

xml复制<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

如果你在IDEA里看到上面那句报错，按这个顺序排查：

1. 确认Project SDK选了17：File -> Project Structure -> Project SDK。
2. 确认Maven的JDK for importer选了17：Settings -> Build Tools -> Maven -> JDK for Importer。
3. 执行mvn clean compile，看控制台用的到底是哪个JDK。

这个问题本身不复杂，但架不住频繁出现。我在实际项目中还遇到过一种更隐蔽的情况：pom里写的17，但CI流水线的服务器上装的是JDK 11，编译直接失败。所以pom里的Java版本号务必跟Dockerfile的基础镜像、CI的JDK版本保持一致，这类配置漂移问题越早统一越好。

3. 题库与多语言设计：让同一道题在不同国家长得不一样

3.1 题目数据模型：两张表解决“题干翻译”和“选项乱序”

题库是答题系统的心脏。国际版题目的数据模型，核心是“题目主表 + 题目翻译表”的设计。

题目主表存的是跟语言无关的公共信息：题目ID、题型、难度、所属活动ID、状态、创建时间。翻译表存多语言内容：语言代码、题干、选项列表、解析、每题对应的本地化文案。

表结构大致如下：

sql复制CREATE TABLE `question` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `quiz_id` bigint NOT NULL COMMENT '所属活动ID',
  `type` tinyint NOT NULL COMMENT '1单选 2多选 3判断 4填空',
  `difficulty` tinyint DEFAULT '1' COMMENT '难度1-5',
  `status` tinyint DEFAULT '1' COMMENT '1草稿 2已发布 3下架',
  `sort_order` int DEFAULT '0' COMMENT '题目排序',
  `created_at` datetime DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_quiz` (`quiz_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `question_translation` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `question_id` bigint NOT NULL,
  `language` varchar(16) NOT NULL COMMENT '语言代码 en/ja/es...',
  `content` json NOT NULL COMMENT '题干和选项的JSON结构',
  `answer_explanation` text COMMENT '答案解析',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_question_lang` (`question_id`, `language`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

为什么用JSON存题干和选项，而不是单独建一张选项表？原因有二。第一，不同题型的选项结构差异巨大：单选题是四个字符串选项，判断题只有对/错，填空题可能根本没有选项。用JSON可以灵活适配。第二，答题时前端需要一次性拿到题目的全部内容，如果选项单独建表，每次取题要额外查一次，多一次IO和一次组装。

content字段的JSON结构大概长这样：

json复制{
  "stem": "Which of the following is a JVM language?",
  "options": [
    {"key": "A", "text": "Java"},
    {"key": "B", "text": "Python"},
    {"key": "C", "text": "C++"},
    {"key": "D", "text": "Ruby"}
  ]
}

标准答案不放在翻译表里，因为正确答案跟语言无关。但是选项的顺序可能因语言而异——这个细节面试里常被问到，后面单独讲。

3.2 双语/多语题库的实现细节：UNICODE、排序规则、字体影响

翻译表设计好了，实际操作中还会遇到几个技术细节。

建表字符集必须用utf8mb4而不是utf8。MySQL里的utf8字符集最多支持3字节的UTF-8编码，正常的中英文、日文假名、韩文都能存，但存不了emoji的4字节编码。答题系统的题面里如果出现emoji字符，用utf8建表会直接报Incorrect string value错误。UTF-8 MB4里的MB4就是“maximum bytes 4”的意思，它是MySQL里完整的UTF-8实现。

JDBC连接串也要显式指定编码：

properties复制jdbc:mysql://localhost:3306/quiz?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

前端拿到JSON格式的题干后，不同语言的文本长度不一样：同样是“请选择正确答案”，英文是23个字符，德语可能更长，中文只需要9个字符。UI设计时按钮宽度、换行规则不能写死，否则做德语版时布局会崩。

还有一个容易被忽略的点：排序规则。MySQL的ORDER BY用的是建表时指定的collation，比如常见的utf8mb4_general_ci，它对英文的排序没问题，但日文五十音、中文拼音跟英文的字典序都不一致。如果后台管理后台需要按题面文字排序，建议直接在主表加一个sort_order字段用于指定题目展示顺序，不要依赖数据库的字符串排序，省得在collation上折腾。

3.3 题目的增删改查与批量导入：lombok编译报错的现场

题目管理后台的CRUD本身不难，难的是批量导入。运营手里拿到的往往是Excel表格，里面有几百道题，分中英日韩四列。这时候用EasyExcel做一个导入接口，前端上传文件，后端解析、校验、分批写入数据库。

EasyExcel的读取是逐行扫描的，解析出一行就回调一次，内存占用远小于POI的WorkbookFactory.create()一次性加载。写导入逻辑时我建议的流程是：

1. 校验表头是否符合模板，语言列命名是否在允许列表内。
2. 逐行读取，先做基础校验：题干不能为空、选项数量是否正确、答案是否在选项范围内。
3. 校验通过的数据先攒在List里，每500条刷一次库。不要一条一条插入，性能差一个量级。
4. 插入完成后统计成功/失败数量，失败行要把行号和原因写入错误日志，返回给运营定位问题。

踩过的坑是lombok的编译问题。项目里大量使用了@Data注解，如果IDEA的lombok插件版本跟JDK 17不匹配，编译时会报错：

java: You aren't using a compiler supported by lombok, so lombok will not work with your project.

这个报错在JDK版本升级后特别常见，lombok通过注解处理器在编译期生成getter/setter，JDK内部API变了，旧版lombok就失灵了。解决方案就是升级lombok依赖到1.18.30及以上版本，同时在IDEA的Settings -> Plugins里确认lombok插件也是最新的。这个问题看似小，但一旦遇到，整个项目所有依赖@Data的地方全部编译失败，排查起来很耗时间。

4. 核心答题流程：从“开始答题”到“交卷判分”的完整链路

4.1 答题会话（Session）的状态机设计

答题不是简单的“提交一次答案”就完事，它有一个明确的生命周期。我设计了四个状态：

code复制NOT_STARTED(未开始) -> ANSWERING(答题中) -> SUBMITTED(已交卷) -> GRADED(已判分)

会话状态在Redis里存一份热数据，在MySQL里存一份冷数据。Redis的key是quiz:session:{userId}:{quizId}，value是会话对象，包含当前答到第几题、每题选择的答案、答题开始时间、最后更新时间。用户断线重连时，前端带会话ID回来，后端从Redis取出会话，判断状态是ANSWERING且未超时的话，直接返回已答进度，实现断点续答。

状态流转的控制逻辑放在SessionService里，关键路径如下：

java复制public QuizSession startSession(Long userId, Long quizId) {
    // 检查该用户是否有未完成会话，有则直接返回，防止重复开启
    QuizSession exist = sessionCache.get(userId, quizId);
    if (exist != null && exist.getStatus() == SessionStatus.ANSWERING) {
        return exist;
    }
    // 无则创建新会话，状态ANSWERING，写入Redis
    QuizSession session = new QuizSession();
    session.setStatus(SessionStatus.ANSWERING);
    session.setStartTime(Instant.now());
    sessionCache.save(userId, quizId, session);
    return session;
}

这里有一个“重复开启会话”的并发问题。用户手抖连点了两次“开始答题”，如果接口没有幂等处理，会创建两个会话。我在代码里利用Redis的SETNX能力做了一次互斥：只有第一次请求能成功写入，第二次请求发现key存在且状态有效，直接返回已有会话，不再新建。

4.2 判分逻辑：单选/多选/填空的判定策略

判分模块我用了策略模式，每种题型一个判分策略，避免一大坨if-else堆在同一个方法里。

定义判分策略接口：

java复制public interface GradingStrategy {
    QuestionType supportedType();
    double grade(String correctAnswer, String userAnswer);
}

单选判定逻辑最简单：用户答案和标准答案完全匹配，拿满分，否则零分。这里注意标准答案的存储方式：不存A这样的选项字母，而是存选项内容。因为国际版中同一道题的选项在英语版是A/B/C/D，在日语版可能标成1/2/3/4，直接按字母比对会因为展示顺序不同而出错。存储时统一存选项的文字内容或唯一ID，展示时再映射到对应语言的字母序号。

多选题的判分规则需要在需求阶段就跟产品确认。有两种常见策略：全对才得分，以及少选得部分分。全对才得分实现简单，但用户反馈差，答对一个选项都不得分很打击积极性。我当时实现的是部分得分：用户选择的集合与正确答案集合完全一致得满分；用户选择是正确答案集合的非空子集得一半分；一旦选择了错误选项，得零分。代码如下：

java复制public double grade(String correctAnswer, String userAnswer) {
    Set<String> correctSet = parseAnswerSet(correctAnswer);
    Set<String> userSet = parseAnswerSet(userAnswer);
    if (correctSet.equals(userSet)) {
        return FULL_SCORE;
    }
    if (correctSet.containsAll(userSet) && !userSet.isEmpty()) {
        return PARTIAL_SCORE;
    }
    return ZERO_SCORE;
}

填空题更麻烦，存在“答案接近但没完全匹配”的情况。比如标准答案是Spring Boot，用户填了SpringBoot。处理思路是判分前先做标准化：去掉所有空格和标点，统一转小写，再比较字符串。如果产品要求支持模糊匹配，可以在标准化之后加一层编辑距离计算，超过阈值视为正确。这个功能可以加开关配置，默认关闭，因为模糊匹配存在误判风险。

4.3 限时机制：Redis过期与本地时钟的时间差

答题活动必然有时长限制，比如整个活动30分钟。实现时用Redis的EXPIRE给会话key设置过期时间，到时间自动失效。

但这里藏着一个容易忽视的问题：Redis的过期时间和服务器的系统时间都可能出问题。

如果服务器时间和Redis时间不同步，你设置的30分钟过期可能实际只有28分钟或32分钟。解决方法是统一时间源，部署时所有机器同步NTP。前端展示倒计时建议以后端返回的expireAt为准，不要基于前端本地时间计算。前端和用户设备的时间差问题尤其普遍，用户手机时间慢了5分钟，他看到的时间就多了5分钟。我当时的做法是后端返回剩余秒数和服务器当前时间戳，前端用serverTimestamp + remainSeconds - now计算剩余时间。

还有一种极端情况：用户答题过程中系统时间被运维调整，会导致Redis里大量会话同时过期。这种属于不可控因素，代码层面能做的防御是：会话过期后，判分接口仍然允许在宽限期（比如2分钟内）提交，只是标记为超时提交，是否计分由活动配置决定。

4.4 防作弊的基本手段：IP限制、切屏检测、答案乱序

答题类产品天然是作弊重灾区。国际版用户分散在不同国家，防作弊不能做得太严格，网络环境复杂，误封会影响正常体验。当时从业务角度做了三道防线。

第一道是IP频率限制。同一个IP在短时间内开启超过N场答题，直接拒绝。用户开了代理或者公司共用出口IP的情况比较多，所以限制阈值放得比较宽，比如60分钟内最多发起10场。

第二道是切屏检测。前端监听visibilitychange事件和blur事件，用户切出App页面就记录一次切屏事件。后端不主动判断作弊，只把切屏次数记录下来，交给运营在人工审核时参考。切屏次数超过阈值（比如3次）的答卷，标记为SUSPICIOUS，不直接进排行榜。

第三道是题目顺序和选项顺序的随机化。给同一个用户下发题目时，题目顺序和选项顺序都打乱。打乱选项顺序时要注意正确答案的关联存储，不能把标准答案对应到错误的选项文本上。我封装了一个shuffleOptions方法，返回打乱后的选项列表和新的正确答案文本，保证缓存里的快照和判分使用同一份数据。

5. 性能与稳定性：并发答题时的服务器到底在忙什么

5.1 高频读接口的缓存设计：题库缓存与题目快照

答题活动一旦开始，用户流量会集中在同一时间涌入。如果没有缓存，每道题都查一次数据库，数据库压力会直接拉满。这个系统里有两层缓存：

活动开始前，管理员发布活动时，将整个题目的核心信息（题目ID、题干、选项、顺序）从MySQL加载到Redis。key设计为：

code复制quiz:questions:{quizId}

value是题目列表的JSON。用户请求题目详情时，直接读缓存，不落库。这里注意一个问题：题目内容从Redis读取后，不能直接把同一个对象引用返回给前端，因为程序中有可能修改这个对象，一旦有并发请求，线程安全问题就会暴露。我用JSON序列化/反序列化做深拷贝，保证每个请求拿到的是独立对象。

答题会话内，用户在提交前，会在Redis里生成一份“答题快照”：

code复制quiz:snapshot:{sessionId}

用于记录用户本场看到的题目顺序、选项顺序和正确答案映射。这个快照是判分的依据，避免用户提交后题目内容被后台修改导致判分不一致。运营可以随时修改题库的题目内容，但不影响正在进行的答题会话。

5.2 防止超卖式的重复提交：答题记录的幂等控制

用户交卷时可能误操作点两次提交按钮，或者弱网环境下前端重试，导致同一份答案被提交两次。如果后端不处理，就会在答题明细表里产生两条重复记录，判分两次，排行榜重复计数。

我的处理方式是在提交接口加幂等闸门。每次创建答题会话时生成一个全局唯一的submitToken，前端交卷时把token一并传过来。后端第一次提交时，用Redis的SETNX把token写入，只有写成功的请求才允许继续执行判分逻辑；重复提交的请求因为token已经存在，直接返回“已提交”状态，不再重复判分。

分布式环境下这个方案天然支持，因为SETNX是原子操作。如果只用MySQL查重，在高并发下容易两个请求同时查到“不存在”，然后同时插入，依然会重复。Redis的原子操作从源头挡住了并发穿透。

5.3 实战压测与内存问题：OutOfMemoryError排查记录

在活动上线前，我用JMeter做了一轮简单压测。500个线程同时请求开始答题、提交答案的接口，压了20多分钟，服务进程直接抛出了java.lang.OutOfMemoryError: insufficient memory。

这个报错在热搜词里也高频出现，说明很多人遇到过。当时排查步骤是这样的：

先看JVM参数。默认的堆内存可能只有物理内存的四分之一，我的服务部署在2C4G的容器里，默认堆只有1G，压测时大量的答题会话对象、JSON序列化缓冲、Redis连接池的对象全堆在堆里，GC来不及回收，直接OOM。第一步调整启动参数：

bash复制java -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar quiz-server.jar

-Xms和-Xmx设置为相同值，避免运行时动态扩容带来的性能抖动。堆从1G扩到2G后，压测能跑通了，但GC日志里发现Full GC频率还是不低。再往下查，定位到两个问题。

一个是我在判分逻辑里用了一个静态的ThreadLocal缓存当前会话上下文，但忘记在finally块里移除。在高并发下线程池里的线程复用时，ThreadLocal里残留的旧会话对象一直不被回收，形成隐式内存泄漏。修复很简单：

java复制try {
    // 业务逻辑
} finally {
    sessionContext.remove();
}

另一个问题是题目快照的序列化方式。我用Jackson的ObjectMapper把整个题目列表序列化到Redis，每个会话都要复制一份快照，几百题的活动，一个快照几十KB，压测时500并发，光快照就是几十MB的内存。后来把不必要的字段（比如标准答案的解析文字）从快照中剔除，只保留判分必需字段，快照体积缩小了三分之二。

6. 盘点那些比功能更值得记录的坑

6.1 编译期报错：JDK 17与旧依赖的兼容性

除了前面提到的lombok问题，JDK 17还有一类常见的兼容坑：使用了反射获取私有字段的旧库。JDK 17强封装了内部API，像sun.misc.Unsafe的常规使用会直接抛IllegalAccessError。当时用了一个老版本的JSON序列化库，在JDK 17下启动就报错。排查过程也很典型：报错堆栈指向的是序列化库，但根源是它内部用了反射访问JDK内部类。处理方式是升级到该库兼容JDK 17的新版本，或者换掉依赖。

给所有准备上JDK 17的人一个建议：从JDK 8升到11跨度还好，升到17要全量检查项目依赖的第三方库版本，特别是老的ORM框架、序列化库、字节码操作库。宁可花半天时间逐个升级依赖，也别让线上环境在启动时打你脸。

6.2 运行时异常：数组越界是如何混进判分逻辑的

压测时还遇到过ArrayIndexOutOfBoundsException，当时很困惑：判分逻辑里只是比较两个字符串集合，怎么会有数组越界？

定位后发现是多选题解析答案时的Bug。前端提交的答案是JSON数组，比如["A","C"]，我用split(",")把它拆开。但如果某个选项的文本里面本身包含逗号，比如选项内容写的是“Spring, Java, and JVM”，前端传过来的答案数组序列化后就成了["Spring, Java, and JVM"]。我按逗号切分，数组长度就变了，遍历时越界。

这个问题的本质是我用了一个不合适的格式来传输结构化数据。修复方式很简单：前后端统一用JSON数组传输，判分时用ObjectMapper解析成List<String>，而不是自己用逗号拼接再拆。这类坑在真实项目中非常典型，很多解析异常不是逻辑写错，而是数据格式设计不合理。

6.3 部署与运维：多时区下定时任务的一个坑

答题系统需要一个定时任务：每天零点把前一日的排行榜快照落库，然后重置今日榜。在国内做这个功能，只需要写一个@Scheduled(cron = "0 0 0 * * ?")就完事。

但用户分布在不同时区时，问题来了：美国东部用户的活动结束时间是UTC次日凌晨5点，欧洲用户是UTC当日23点。如果服务部署在中国境内，JVM默认时区是Asia/Shanghai，0 0 0 * * ?执行时，纽约用户那边是中午11点，根本不对。

解决方式有二。第一，定时任务全部基于UTC时间执行，每天UTC零点算“一天”的边界。跑批逻辑里判断用户所在的时区，把UTC零点映射到用户当地时间零点再统计。第二，用分布式定时任务框架（比如XXL-JOB）配置多个任务，按不同区域分别注册不同时区的调度。我当时因为排行榜本身有跨时区统计的需求，在代码里用ZoneId显式处理每个用户的时区转换，没有依赖系统默认时区。

部署时统一设置JVM时区为UTC也是一个规避技巧：

bash复制java -Duser.timezone=UTC -jar quiz-server.jar

数据库连接串也加了serverTimezone=UTC保证连接层的时间处理是确定的。这样跑批、日志时间戳、API返回的时间字段全部是UTC，前端拿到时间戳再按用户时区渲染。这套方案的好处是后端逻辑简单一致，不会有“中间某层悄悄做了本地时区转换”的幽灵问题。

如果问我要不要重新做一次这个系统会改什么，我的答案是：一开始就把“按用户时区聚合”的需求前置到表结构设计里。现在排行榜表是按UTC天分区的，但运营看数据时总想按当地日期看，每次都要在报表层做一层转换。这个不算代码Bug，属于需求设计时没有想透的债，趁早把时间聚合维度做进表结构，后面能省很多事。