企业官网建设流程全解析

简介：一套面向Java中高级开发者的SaaS短链接管理系统源码，聚焦长链接缩短、安全监控与营销数据分析，帮助企业或个人用户提升链接传播效率与业务转化。压缩包共219个文件，以188个Java源文件为主，辅以14个XML、11个YAML完成配置管理，2个SQL初始化数据库，还有Lua脚本、HTML页面等，整体仅563KB，结构紧凑。系统按admin、gateway、aggregation、project等模块拆解，覆盖后台管理、网关控制、数据聚合与核心业务，源码中包含RedisStreamConfiguration及短链接统计消费者等实现，可学习基于Java的流式消息处理与PV、UV、UUId指标统计。已有389人浏览学习，适合想掌握短链接系统设计、SaaS后台架构或数据追踪方案的技术人员参考复用。

1. 短链接离我们不远：为什么 Java 团队要自己写一套 SaaS 短链接管理系统

做增长、做投放、做短信营销的团队，早晚会碰到同一个诉求：长链接又长又丑，放进短信按字计费，放进海报连二维码都撑满——短链接不是工具，是基础设施。而这个标题里的关键词是「基于 Java」「SaaS」「源码」，翻译成业务语言就是：不是做个单机版缩链工具，而是要做一套能卖、能租、能隔离租户数据、能统计点击的短链接管理系统。我在给几家客户公司做内部基建时，发现大多数团队的第一步不是选型，而是先问「能不能直接用第三方短链服务」。答案是能用，但你把点击数据、用户行为、渠道归因全交出去了，SaaS 客户可不愿意。

所以这套源码的价值在于：它把「发号器、跳转链路、访问统计、租户隔离」这四件事用 Java 技术栈串了起来，既能让新手通过源码理解短链接的完整闭环，也能让熟手直接拿去改造成生产级服务。适合的人群很明确：准备自建短链接中台的 Java 工程师、做 To B 业务需要给客户提供短链能力的团队，以及想拿一个既有业务深度又有设计亮点的源码来拆解学习的人。接下来我按自己的实现思路，把这套系统的设计逻辑、核心代码、多租户细节和常见坑拆开讲。

2. 短链接系统的核心链路：从发号器到 302 跳转，SaaS 版多了哪三层

短链接系统的原理一句话能讲完：把一串长 URL 映射到一个短码，访问短域名加短码时，服务端查映射关系并 302 跳回长 URL。但把它做成 SaaS 服务，复杂度会往上叠三层：第一层是短码不能重复且不能按顺序被猜到，否则别人可以遍历你的短链；第二层是跳转要做缓存和容灾，否则热点短链一上来数据库就扛不住；第三层是每个租户的数据要隔离，A 租户的短链不能出现在 B 租户的统计报表里。这三层分别对应发号器、跳转链路和租户模型，下面一个一个拆。

2.1 发号器选型：雪花 ID 还是自增 ID，多租户下不能随便选

短码本质是一个唯一 ID 的 Base62 编码，所以发号器的选择直接决定短码的生成效率和外泄风险。常见方案有两种：一是数据库自增 ID 加步长，比如部署三台实例，每台分别以 1、2、3 为起始值、步长 3 递增；二是用雪花算法生成 64 位趋势递增 ID，再截取后段做 Base62 编码。自增 ID 的优点是完全有序、短码最短，缺点是 ID 可被顺序遍历，竞对可以每天调用你的接口枚举你的短链数量，这在 SaaS 场景里属于不可接受的隐私漏洞。

雪花 ID 在单机短链场景里表现尚可，但放到 SaaS 多租户下有一个隐藏问题：短码会变长。雪花 ID 是 64 位长整型，转成 Base62 后大约 11 位字符，而使用数据库自增在低并发下能做到 6 位以内。短码长度直接影响短信计费和二维码容错率，所以我在做这套设计时更倾向混合方案：使用 Redis 的 INCR 命令为每个租户维护独立的短码段，然后用租户 ID 参与混淆，不让短码呈现明显的连续递增规律。下面这段代码是核心发号逻辑的骨架：

public String generateShortCode(Long tenantId, String longUrl) { // 每个租户单独一个计数器，key 里带上租户 ID，避免全局共用一个序列号 String counterKey = "shortlink:counter:" + tenantId; long sequence = redisTemplate.opsForValue().increment(counterKey); // 把租户 ID 与序列号做一次可逆混淆，防止短码被顺序遍历 long mixed = mix(tenantId, sequence); return base62Encode(mixed); }

这里有两个参数需要留意：一是 Redis 计数器的增量步长，多实例部署时默认步长要大于等于实例数，否则会撞码；二是 mixed 的位数，租户 ID 占的位越多，短码可用位越少，需要预留足够的位宽给序列号。生产环境我会把 Redis 计数器持久化开启，配合 AOF 每秒刷盘，避免 Redis 重启后计数器回退导致短码重复。实际项目中我见过因为 Redis 没开持久化，重启后短码重复生成、部分历史链接被覆盖的案例，属于典型的「开发环境没事、上线即翻车」类问题。

2.2 跳转逻辑与缓存穿透：一次点击背后的 Redis 和 MySQL 配合

短链接跳转接口是整个系统压力最大的入口，因为用户每次点击都会请求这里。直接查 MySQL 是最简单也最容易被打爆的做法，所以我一般会加两层缓存：本地 caffeine 缓存和 Redis 缓存。查询顺序是本地缓存 → Redis → MySQL，查到 MySQL 后回填 Redis 和本地缓存。跳转接口的关键点在于，缓存过期瞬间如果碰到热点短链，大量请求会同时穿透到数据库，这就是典型的缓存击穿问题。解决思路是加互斥锁，让同一短码在缓存失效时只有一个请求去查数据库。

public String resolveUrl(String shortCode) { String cacheKey = "shortlink:url:" + shortCode; String url = redisTemplate.opsForValue().get(cacheKey); if (url != null) { return url; } // 加分布式锁，防止缓存击穿打爆数据库 String lockKey = "shortlink:lock:" + shortCode; boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofMillis(300)); if (locked) { try { url = shortLinkMapper.selectUrlByShortCode(shortCode); if (url != null) { redisTemplate.opsForValue().set(cacheKey, url, Duration.ofHours(24)); } } finally { redisTemplate.delete(lockKey); } } else { // 其他线程让出 CPU，短暂自旋后重试读取缓存 Thread.sleep(50); return resolveUrl(shortCode); } return url; }

这段代码有几个值得注意的参数：锁的过期时间设 300 毫秒，是为了防止持有锁的线程异常退出时锁不被释放；如果一次数据库查询超过 300 毫秒，锁就会提前失效，所以这里要和 MySQL 慢查询阈值对齐排查；缓存 TTL 我设 24 小时是针对通用链接的默认值，VIP 租户的短链可以单独配置更长的缓存时间。另外，重试逻辑用了简单递归，生产环境建议改成固定次数的循环，否则锁竞争激烈时递归过深会浪费栈空间。跳转状态码我推荐用 302 而不是 301，301 会被浏览器缓存重定向结果，后续想改目标地址时用户的浏览器不一定会发新请求，统计也会失真。

2.3 SaaS 维度：租户隔离、子域名与套餐限流的落地设计

SaaS 短链接系统的第一个设计决策是：所有租户共用一套短码池，还是每个租户独立短码池。共用池的好处是短码利用率高、短码更短，坏处是统计和风控维度需要额外挂租户标识；独立池的好处是隔离彻底、排查方便，坏处是短码位宽被切碎，短码整体变长。做 To B 产品时我会选择共用短码池，用一个 tenant_id 字段做隔离，因为大部分租户的短链量级在几十万到几百万条，共用池的编码长度优势非常明显。

子域名是 SaaS 短链最容易忽略的设计点。客户用自己的品牌域名做短链是很常见的需求，所以系统要支持配置每个租户的独立域名，比如 a.com 和 b.com 的短链解析到同一套服务，但根据 Host 头区分租户。这个功能在做网关或拦截器时就要预留。套餐限流则是对应 API 的流量控制，每个租户的 QPS、每日生成条数、短链过期策略都要可配置，技术实现可以用令牌桶，也可以在网关层做简单的计数器限流。我在设计数据库时会把套餐配置单独建表，而不是把限流参数硬编码在每个租户表里，否则后续调套餐要改全表数据。

3. Java 实现与源码目录设计：Spring Boot + MyBatis 的分层结构怎么搭

如果你拿到一套短链接系统源码，第一件事应该是看包目录。好的目录结构能直接告诉你系统的扩展方向，而不是让你在几百个类里找入口。这套系统我推荐的包结构遵循 Spring Boot + MyBatis 的标准分层，但会在业务模块上做垂直切分，把短链生成、跳转、统计、租户管理拆成独立的包，这样后续做模块隔离或服务拆分时不会伤筋动骨。

3.1 后端分层：controller、service、mapper 与事件驱动的统计链路

controller 层只做参数接收和结果返回，不写业务逻辑。短链系统的 controller 数量很少，核心就是生成接口、解析接口、统计查询接口和租户管理接口。service 层承担业务编排，比如生成短链时先校验租户配额、再检查长 URL 合法性、最后调用发号器生成短码。mapper 层对应 MyBatis 的数据库操作，这里要特别注意统计相关查询不要在主库执行，否则报表类的慢查询会拖垮核心跳转链路。

统计链路我会用 Spring 的事件机制解耦。跳转接口只负责更新 Redis 计数器，把点击明细丢进事件里；监听到事件后异步写访问日志表。这样做的好处是跳转接口的响应时间不依赖数据库写入，压测时能稳定保持在 10 毫秒以内。异步写日志最怕丢数据，所以我会把事件封装成包含租户 ID、短码、IP、UA、时间戳的消息体，并用有界队列承接，队列满时降级为直接丢弃并告警——在短链统计场景里，丢万分之一的点击量是可以接受的，但主链路延迟飙升是不可接受的。

3.2 核心表结构设计：短链接表、访问日志表与租户表

短链接表是系统的核心，字段设计要兼顾查询效率和业务扩展。我见过太多人把短码、长 URL、租户 ID、创建时间这几个字段建完就收工，结果后续加状态、加过期时间、加平台分类的时候只能重建表。合理的表结构应该预留状态字段和扩展字段，并用联合索引覆盖高频查询。访问日志表是另一个重点，它和短链表是典型的一对多关系，但日志表不能和业务表放在同一个库的同一张表里，按天分表是短链统计的常规做法。

CREATE TABLE `t_short_link` ( `id` bigint NOT NULL AUTO_INCREMENT, `short_code` varchar(16) NOT NULL COMMENT '短码', `long_url` varchar(2048) NOT NULL COMMENT '原始长链接', `tenant_id` bigint NOT NULL COMMENT '租户ID', `domain` varchar(128) DEFAULT NULL COMMENT '独立域名', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态: 1启用 0禁用', `expire_time` datetime DEFAULT NULL COMMENT '过期时间', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_tenant_short_code` (`tenant_id`, `short_code`), KEY `idx_short_code_domain` (`short_code`, `domain`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='短链接表';

这个表结构里最关键的三个设计：一是联合唯一索引uk_tenant_short_code，保证同一个租户下短码不重复，同时给租户级查询提供索引；二是domain字段，让子域名绑定成为可能；三是expire_time，做定时任务扫描过期短链时，这个字段必须有索引。long_url用 varchar(2048) 而不是 text，是为了避免 MyBatis 对 text 类型的额外映射开销，同时 2048 足够覆盖绝大多数合法 URL。访问日志表我会按visit_date做分表，主键用雪花 ID，并单独存短码和租户 ID 两个查询维度。

3.3 关键代码：跳转接口、缓存策略与异步落库

跳转接口是整套系统里最不应该出问题的代码，它短小精悍，但对并发和性能的要求最高。跳转前要检查短链状态、是否过期，命中后用 302 返回长 URL，同时把点击事件发布出去。异步落库的代码我放在事件监听器里，用线程池执行写入，线程池的核心线程数、最大线程数和队列容量需要根据预估 QPS 调整。

@Component public class VisitLogListener { // 线程池参数：核心8，最大16，队列5000，丢弃策略为 CallerRunsPolicy private final ThreadPoolExecutor executor = new ThreadPoolExecutor( 8, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(5000), new ThreadPoolExecutor.CallerRunsPolicy() ); @Async("visitLogExecutor") @EventListener public void onVisitEvent(VisitEvent event) { try { visitLogMapper.insert(event.toVisitLog()); } catch (Exception e) { log.error("visit log insert failed, event: {}", event, e); } } }

这段代码有三个参数值得展开：核心线程数 8 意味着系统空闲时也常驻 8 个线程处理日志写入；最大线程数 16 是处理突发流量的上限；队列容量 5000 表示积压超过 5000 条任务时触发拒绝策略。我选了 CallerRunsPolicy 而不是 AbortPolicy，因为前者在队列满时让调用方线程自己执行写入任务，天然实现了背压，不会因为拒绝而丢日志，但代价是跳转线程会被拖慢。如果你的系统对跳转延迟极其敏感，可以换成 DiscardPolicy 并搭配监控告警，优先保主链路。线程池的名称visitLogExecutor需要在配置类里显式声明，否则 Spring 的@Async注解会使用默认的 SimpleAsyncTaskExecutor，那个执行器每次都会新建线程，高并发下会直接把内存打满。

4. 多租户隔离与关键参数：从数据库到 Redis 的配置清单

多租户隔离是这套系统的灵魂，也是「SaaS」三个字母和普通短链工具最本质的区别。隔离做不好，租户间的数据互相泄露，技术债会严重到推倒重来。我在设计时会把隔离分成三层来做：数据层隔离保证查询不出界，缓存层隔离保证 Redis 的 key 不冲突，业务层隔离保证套餐能力不越权。三层各管一摊，缺一不可。

4.1 租户字段还是独立库：SaaS 短链系统的两种隔离方式

独立数据库库隔离的方案安全性最高，每个租户一套库表，但运维成本跟着租户数量线性增长，而且你要为每个租户单独执行建表脚本、单独配置备份策略。共享表加租户 ID 字段的方案维护成本低，但所有租户的数据混在物理表里，查询时漏加租户条件就是事故。短链接系统的表结构相对统一、查询模式固定，我倾向用共享表加租户 ID 的方案，配合 MyBatis 拦截器做数据权限控制，而不是靠每个开发手写where tenant_id = ?；手写漏一处，就是一处数据泄露的隐患。

实现层面我会做一个自定义的 MyBatis 拦截器，拦截所有查询语句，自动在 SQL 尾部追加and tenant_id = #{当前租户ID}。租户 ID 从登录态或 API 密钥解析出来，存放在 ThreadLocal 中。这个方案的边界在于统计类的聚合查询和定时任务：定时任务扫描过期短链时是全局视角，不能被租户拦截器误伤，所以拦截器要支持白名单机制。这个细节在实际项目中很容易踩坑，后面避坑章节会展开。

4.2 缓存 TTL、连接池与线程池：一组可以被直接抄走的参数

多租户场景下的缓存设计跟单机版有一个显著区别：Redis 的 key 必须带上租户 ID 或域名，否则两个租户如果碰巧生成了相同的短码，缓存就会串数据。我在生成短码时已经保证了全局唯一，但缓存 key 仍然建议使用shortlink:url:{tenantId}:{shortCode}的格式，多一层隔离防御。缓存 TTL 的设置要考虑两个极端：太短，热点短链反复穿透到 DB；太长，短链被禁用后缓存里还能跳转。通用 TTL 我设 24 小时，但短链被禁用时主动删除对应缓存。

连接池参数直接决定系统的并发上限。Druid 或 HikariCP 我常用 HikariCP，Spring Boot 默认就是它。核心配置是maximum-pool-size和minimum-idle，对于短链这种读多写少的系统，我会把 maximum-pool-size 设为 CPU 核数乘以 2 再加 1，而不是无限调大。连接池过大的后果是数据库端连接数被打满，反而拖垮数据库。Redis 连接池同理，Lettuce 默认的共享连接在高并发下够用，但如果你用 Jedis，max-total不要超过 100，否则 Redis 实例的连接数会成为新的瓶颈。

4.3 安全与风控：短链被滥用时 Java 侧怎么兜底

短链接天然是网络钓鱼和恶意跳转的温床，SaaS 服务如果不做风控，很快会被黑产盯上。我在生产环境会做三道防线：生成侧拦截、跳转侧检测、管理侧封禁。生成侧拦截是指创建短链时对长 URL 做域名白名单校验，至少校验域名是否在禁止列表中；跳转侧检测是指对访问频率异常的短链或者 IP 段做实时限流；管理侧封禁则是提供运营后台的封禁接口，一旦发现恶意短链，可以立即把短码状态置为禁用。状态禁用后，跳转接口的查询要把状态字段纳入缓存 key，或者走缓存删除，否则封禁不生效。

跳转侧的高频访问检测我一般用 Redis 的计数器，对同一个短码统计每秒请求数，超过阈值就返回安全提示页而不是直接跳转。这个阈值要设置得足够高，避免误伤正常的营销活动流量，比如大促期间一个短链在一分钟内被点击几万次是正常的。所以在做套餐设计时，限流阈值应该按租户套餐级别配置，而不是全局共享同一套阈值。安全兜底这段逻辑不需要多复杂，但有没有这段代码，决定了这套系统敢不敢拿去面对真实公网流量。

5. 避坑与排查：短链接系统上线后最常见的 5 个翻车现场

任何系统上线后都会暴露设计时看不到的问题，短链接系统尤其如此。因为它的访问链路短，任何一个环节的异常都会直接反馈到跳转成功率上。下面这五个问题是我自己在实际项目中踩过或帮别人排查过的，每条都按「现象 → 原因 → 解决」的顺序写，希望能给你省点排查时间。

5.1 短链跳转偶发 404：缓存与数据库不一致的治理

现象是短链刚生成时必现可跳转，但运行一段时间后偶发 404。最典型的案例是短链过期后仍留在 Redis 里，用户点击时缓存命中返回了 URL，但数据库里的记录已经被定时任务标记为过期；反过来也出现过缓存里没有、数据库有，但缓存回填失败了的情况。这个问题的根源是缓存和数据库两套存储的生命周期没有被统一管理。

解决思路分三步：短链的新增、禁用、过期都必须主动删除 Redis 缓存，不能依赖 TTL 自然过期；定时任务扫描过期短链时，处理完数据库后要再删一次缓存；跳转接口遇到数据库记录不存在但缓存命中时，要把缓存删掉再返回 404，避免脏缓存一直残留。我在代码里加了一个小技巧：跳转接口返回 404 前，把短码写入一个标记为「已失效」的 Redis 集合，后续同样的请求直接拦截，不回源数据库，减少无效查询。

5.2 点击量对不上账：异步统计丢数据的排查思路

现象是报表里某一天的点击量明显少于网关日志里的请求数，或者对不上渠道统计的数据。原因基本出在异步落库环节：线程池拒绝策略把任务丢弃了，或者事件监听器抛异常时没有兜底，又或者 Redis 计数器本身有丢失。公网用户访问短链时可能不会等完整链路走完，比如手机端弱网环境下请求中断，服务端线程已经完成了跳转，但后续的异步写入任务还没执行就随着线程池的关闭被丢弃。

排查方法是分两步验证：先对比 Redis 计数器和 MySQL 日志表的总数，如果 Redis 多而 MySQL 少，说明是异步写入环节丢了；再查看应用日志里有没有拒绝执行的堆栈，CallerRunsPolicy 策略下一般不会抛拒绝异常，但如果用的是 AbortPolicy，会看到TaskRejectedException。解决时我在生产环境做了双写补偿：每次跳转先在 Redis 用INCR更新总点击量，异步任务只负责写明细日志，报表查询时以 Redis 总数为基线，明细缺失部分允许一定误差。这样对于绝大多数商业分析场景，误差已经可以接受。

5.3 上报接口被刷导致大量无效日志：频率限制与签名校验

现象是短链点击量突然暴涨，数据库日志表每分钟新增几万条，且大量点击的 IP 和 UA 高度相似。原因通常是短链被刷量工具盯上了，或者竞对在恶意攻击你的跳转接口。这种事在短链接服务里太常见了，黑产刷量、羊毛党刷收益都靠这个。短链系统不能像内部系统那样假设所有请求都来自自己的 App，它天然是公网开放接口，必须默认请求不可信。

我一般会在跳转接口加两层防护：第一层是单 IP 频率限制，用 Redis 记录同一个 IP 在单位时间内的请求次数，超过阈值直接返回 429；第二层是短码维度的限流，同一个短码的 QPS 超过套餐阈值时返回安全提示页。被刷出来的大量无效日志虽然不影响主链路，但会占满磁盘和数据库写入带宽，所以日志表要设置写入配额，超过配额后丢弃日志并触发告警。签名校验对这个场景帮助不大，因为浏览器点击跳转时没法带签名，但如果你提供 API 供第三方调用生成短链，API 密钥的频率限制是必须的。

5.4 长链接里带特殊字符导致生成失败：URL 编码问题

现象是用户在后台粘贴了一个带中文参数或特殊符号的长链接，生成短链时报参数错误，或者生成后跳转过去变成乱码。原因基本是长 URL 没有做编码处理就存库了；URL 里常见的&、?、=、%在传递过程中会被解析成不同含义，甚至被某些框架的安全过滤器拦截。短链接系统的输入天然包含这些字符，所以这类问题几乎是新手上线必踩。

解决方法是分两步：前端提交前先对长 URL 做encodeURIComponent编码，后端收到后再decode一次存入数据库，存的是标准 URI 编码后的明文；跳转时直接返回数据库里的原始字符串，让浏览器自行处理。要注意的是别在跳转时再编码一次，否则浏览器会看到双重编码后的乱码。我在代码里写了校验：存入前先用java.net.URI解析一次，解析失败直接拒绝生成，这样能在入口拦截掉大量非法格式的链接。

5.5 多租户数据串号：拦截器漏配置导致的的资损级 Bug

现象是某租户反馈在统计报表里看到了不属于自己域名下的短链记录，或者自己在后台创建的短链在另一个租户的列表里出现。这个问题的严重程度是资损级的——SaaS 系统一旦数据串号，客户信任基本归零。原因几乎都是同一个：查询 SQL 漏了tenant_id条件。特别是分页查询和统计查询，写 SQL 时容易只关注业务条件而漏加租户维度。

解决方式是不要把租户条件的控制权交给 SQL 编写者，而是交给框架。我在系统里实现了 MyBatis 拦截器自动追加租户条件，同时在 mapper XML 里禁用不带租户条件的全表查询。这里有一个关键配置：拦截器要对「查询」和「更新」都生效，更新语句漏了租户条件会直接导致跨租户数据覆盖。为了避免拦截器误伤运维类的全局操作，我建了一张白名单表维护不需要拦截的 Mapper 方法名，白名单的变更要走审批流程。上线前我还会写一个自动化测试用例，模拟两个租户的 Token 分别查询数据，断言结果集没有任何交叉，这个测试用例放在 CI 里每次发版都会跑一遍。

6. 从能跑到能上线：短链系统的压测、监控与上线前检查清单

短链接系统上线前最值得做的一次压测是跳转接口的压测，因为这是所有流量的必经之路。用 JMeter 或 wrk 模拟并发请求，重点观察两个指标：P99 响应时间和数据库连接池的活跃连接数。我见过很多系统在压测时单接口 QPS 很好看，但一接真实流量就出问题，原因是没有把 Redis 缓存命中率纳入监控。上线后的第一周我会盯三个面板：Redis 命中率、跳转 302 的状态码分布、异步日志写入的积压数。命中率低于 95% 就要检查是不是缓存 key 设计不合理；302 占比骤降说明跳转逻辑可能有异常；日志积压数持续上涨说明线程池配置跟不上流量。

还有一个容易被忽略的验证步骤是短链的生命周期测试。新生成的短链要能跳转，禁用后要立即失效，过期后要返回友好提示页，删除后再次访问不能出现回光返照式的缓存命中。这些操作在开发环境都能通过，但生产环境的缓存层级更多——CDN、浏览器缓存、Redis、本地缓存——每一层都可能让失效变得不彻底。所以我会在预发环境用 curl 带不同的 Cache-Control 头反复验证，确认服务端返回的响应头没有让浏览器长期缓存跳转结果。HTTP 响应头里加Cache-Control: no-store是禁止浏览器缓存 302 的一种有效手段，对统计准确性和封禁及时性都有帮助。

这套系统做下来，我最深的体感是：短链接看起来简单，但「简单」只停留在原理层面，业务设计才是真正的分水岭。单机版缩链工具一小时能写完，SaaS 化之后要面对的是租户隔离、套餐限流、数据隔离、防刷安全这些持续性问题。如果你手里的项目已经走到需要自建短链这一步，我建议先从这套 Java 源码的目录结构开始拆解，把发号器、缓存策略、租户字段这三个设计点吃透，再按自己的业务场景替换掉统计维度和风控策略。希望这些从实际项目里攒下来的参数和踩坑经验，能帮你在自建短链接系统时少走几趟弯路。

本文还有配套的精品资源，点击获取