Java短链接系统源码解析：Spring Boot实现短码生成、访问统计与AB测试

简介：这是一份面向Java后端开发者与全栈学习者的短链接生成工具完整源码，聚焦链接管理、访问数据统计与AB测试等实际业务场景，适合希望深入理解短链系统架构、或需要二次开发搭建自有链接服务的中级开发者参考。资源包共280个文件，压缩后约1.44MB，以187个Java源文件为核心业务实现，辅以19个Vue组件与11个JavaScript文件构建前端交互，另有XML、YAML等配置及PNG、SVG等静态资源，前后端结构完整。目前已有330人学习下载。源码实现了将原始网页链接缩短为简洁短链，并记录每次访问的详细信息，支持按地区分布、设备类型等维度生成统计图表，同时允许随时修改短链跳转目标、批量创建链接，为链接管理与数据洞察提供了一套可运行的工程范例，便于读者研究短链生成算法、统计埋点与前后端协作方式。

1. 从一堆.java文件里翻出一个能跑的短链接系统

拿到「基于 Java 的短链接生成工具」这个源码包时，我第一反应不是兴奋，而是先数了数目录里的东西：187 个 Java 源文件、19 个 Vue 组件、11 个 XML 和 JSON 配置，外加.eslintrc.cjs、base.css、main.css、.env.development这些前端工程痕迹，还有一个short-Link.iml的 IDEA 模块文件。这说明它不是那种「一个Main.java打天下」的课程作业，而是一个前后端分离、能真正跑起来做链接管理的工程。短链接这东西看着简单——把长 URL 压成http://xx.cn/aB3dE就完事——但真落到生产里，访问量统计、地区分布、设备识别、AB 测试分流、批量创建、随时改跳转目标，每一项都是独立的坑。这份源码把八大功能都塞进去了，适合两类人：一是想拿它当 Java Web 课程设计或毕业设计的底稿，二是想研究短链接系统怎么在 Spring Boot 里落地统计和 AB 测试的工程师。下面我按「它是什么 → 怎么跑起来 → 核心逻辑怎么改 → 哪里会翻车」的顺序拆一遍。

2. 环境搭建与首次启动：把 187 个 Java 文件跑起来

2.1 先看清技术栈和目录结构再动手

这个项目是典型的 Spring Boot + MyBatis-Plus + Vue 组合。后端负责短链生成、跳转重定向、访问日志落库和统计聚合，前端用 Vue 做管理后台，展示图表和链接列表。目录里出现.env.development说明前端走的是 Vite 或 Vue CLI 的环境变量机制，base.css和main.css是全局样式，notfound.html是 404 兜底页，favicon.ico和index.html是标准前端入口。short-Link.iml是 IntelliJ IDEA 的模块描述文件，用 IDEA 打开根目录就能自动识别为 Maven 或 Gradle 工程。

我一般拿到这种包，先不急着run，而是做三件事：确认 JDK 版本、确认数据库脚本、确认前端依赖能不能装上。因为 187 个 Java 文件里大概率用了 Java 8 以上的特性（比如 Stream、Optional、LocalDateTime），JDK 版本不对会直接编译失败。数据库方面，短链接系统至少要两张核心表：一张存短码和原始 URL 的映射，一张存访问日志。MyBatis-Plus 的实体类会通过注解映射表名，所以建表语句必须和实体字段对齐，否则启动就报Unknown column。

2.2 后端启动：JDK、Maven 和数据库三件套

先确认环境，再改配置，最后启动。顺序错了会浪费很多时间在无意义的报错上。

# 1. 确认 JDK 版本，项目一般要求 8 或 11 java -version # 2. 确认 Maven 可用 mvn -v # 3. 进入项目根目录，先只编译不运行，看有没有依赖缺失 mvn clean compile -DskipTests

编译通过后，去找application.yml或application.properties（通常在src/main/resources下），改数据库连接。短链接系统的数据库名一般叫short_link或类似，连接串里要带上serverTimezone和useUnicode参数，否则中文和时区会出问题。

spring: datasource: url: jdbc:mysql://127.0.0.1:3306/short_link?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

改完配置后执行建表。如果源码包里带了.sql文件，直接导入；如果没有，就根据实体类字段手写。核心表结构大致如下：

建完表再mvn spring-boot:run，看到Started Application in x seconds就算后端起来了。默认端口一般是 8080，如果被占用就在配置里改server.port。

2.3 前端启动：Vue 工程和.env.development的坑

前端在src/main/resources/static或独立的frontend目录下。先npm install，再npm run serve。.env.development里通常定义了VUE_APP_BASE_API或VITE_API_BASE_URL，指向后端地址。如果前端启动后接口 404，九成是这个变量没配对，或者后端没开跨域。

// .env.development 常见内容 VUE_APP_BASE_API = 'http://localhost:8080'

跨域问题在后端加一个配置类就能解决，常见做法是写一个CorsConfig实现WebMvcConfigurer，重写addCorsMappings。这个源码包里如果有config包，大概率已经带了，没有就自己补一个。前端跑起来后，登录管理后台，试着创建一条短链接，看能不能生成短码并跳转。这一步通了，整个系统就算活了。

3. 短链生成与跳转的核心逻辑：短码算法和重定向

3.1 短码怎么生成：自增 ID + 进制转换是主流

短链接系统的核心就两件事：把长 URL 映射成一个短码，以及访问短码时 302 重定向到原始 URL。短码生成常见有三种方案：随机字符串、哈希取模、自增 ID 转进制。这份源码用的是哪种，看ShortLinkService或ShortCodeGenerator类就知道。我一般推荐自增 ID + 62 进制转换，因为无冲突、可预测长度、实现简单。

public class Base62Util { private static final String CHARS = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; private static final int BASE = CHARS.length(); // 将自增 ID 转成 62 进制短码 public static String encode(long id) { StringBuilder sb = new StringBuilder(); while (id > 0) { int remainder = (int) (id % BASE); sb.append(CHARS.charAt(remainder)); id /= BASE; } return sb.reverse().toString(); } // 短码还原成 ID，用于查询 public static long decode(String code) { long id = 0; for (int i = 0; i < code.length(); i++) { id = id * BASE + CHARS.indexOf(code.charAt(i)); } return id; } }

这段代码的逻辑是：数据库主键自增，拿到 ID 后用 62 进制转成短码存库。encode里不断取余、除基、反转，decode反向累加。参数CHARS的顺序决定了短码字符集，改顺序不影响功能但会影响已有短码的解析，所以上线后不要动。如果源码用的是哈希方案（比如 MurmurHash 后取模），要注意哈希冲突处理——通常做法是冲突时加盐重算，或者查库发现已存在就换一个。

3.2 跳转逻辑：302 还是 301，以及缓存怎么加

短码生成后，访问http://域名/{code}时，Controller 会查库拿到原始 URL，然后返回重定向。这里有个关键选择：用 301 还是 302。301 是永久重定向，浏览器会缓存，后续访问不再请求服务器，统计就丢了；302 是临时重定向，每次都走服务器，统计准确。短链接系统要统计访问量，必须用 302。

@GetMapping("/{code}") public void redirect(@PathVariable String code, HttpServletResponse response) throws IOException { // 先查缓存，缓存没有再查库 String originalUrl = shortLinkService.getOriginalUrl(code); if (originalUrl == null) { response.sendRedirect("/notfound.html"); return; } // 异步记录访问日志，不阻塞跳转 accessLogService.asyncRecord(code, request); response.setStatus(HttpServletResponse.SC_FOUND); // 302 response.sendRedirect(originalUrl); }

这段逻辑里，asyncRecord是关键。如果同步写访问日志，每次跳转都要等数据库插入，高并发下响应会变慢。常见做法是用@Async注解或者丢到消息队列里异步处理。参数上，SC_FOUND就是 302，别写成SC_MOVED_PERMANENTLY（301）。另外，如果源码里加了 Redis 缓存，查库前先查缓存，缓存过期时间一般设 1 到 24 小时，看业务对实时性的要求。

3.3 访问统计与地区设备识别：日志表怎么设计

访问统计的数据来源就是access_log表。每次跳转时，从HttpServletRequest里拿 IP、User-Agent，然后解析出地区和设备类型。IP 转地区一般用离线库（比如 ip2region）或者调第三方 API，源码里如果没带离线库，可能只存了 IP，地区解析是后续扩展点。设备识别靠 User-Agent 字符串匹配，判断是移动端还是 PC 端。

public void asyncRecord(String code, HttpServletRequest request) { AccessLog log = new AccessLog(); log.setShortCode(code); log.setIp(getClientIp(request)); log.setUserAgent(request.getHeader("User-Agent")); log.setDevice(DeviceUtil.parse(request.getHeader("User-Agent"))); log.setAccessTime(LocalDateTime.now()); accessLogMapper.insert(log); }

getClientIp要注意反向代理场景，不能直接request.getRemoteAddr()，得依次检查X-Forwarded-For、X-Real-IP等头。DeviceUtil.parse就是简单的字符串包含判断，包含Mobile就是移动端，包含Windows就是 PC。统计图表的数据靠 SQL 聚合，比如按天分组算访问量、按地区分组算分布。这部分 SQL 一般写在 Mapper XML 里，用GROUP BY和COUNT就能出结果。

4. AB 测试与批量创建：多目标分流和性能边界

4.1 AB 测试分流：权重怎么算，流量怎么分

AB 测试是这份源码里比较有含金量的功能。同一个短码，可以配置多个目标 URL，按权重分流。比如 A 组跳url-a占 70%，B 组跳url-b占 30%。实现方式通常是查库拿到该短码的所有目标配置，然后按权重随机选一个。

public String selectTarget(String code) { List<AbTestConfig> configs = abTestMapper.selectByCode(code); int totalWeight = configs.stream().mapToInt(AbTestConfig::getWeight).sum(); int random = ThreadLocalRandom.current().nextInt(totalWeight); int cumulative = 0; for (AbTestConfig config : configs) { cumulative += config.getWeight(); if (random < cumulative) { return config.getTargetUrl(); } } return configs.get(0).getTargetUrl(); // 兜底 }

这段代码用累积权重法做随机选择。totalWeight是所有组权重之和，random落在哪个累积区间就选哪组。参数weight是整数，建议总和设为 100 方便理解，但不是必须。注意ThreadLocalRandom比Random在高并发下性能更好。如果源码里用的是Math.random()，也能用，但并发量大时会有竞争。

4.2 批量创建：循环插入还是批量插入

批量创建短链接时，如果循环调单条插入，1000 条就是 1000 次数据库往返，性能很差。常见优化是攒一批用insertBatchSomeColumn或手写<foreach>批量插入。MyBatis-Plus 有saveBatch方法，底层是 JDBC 批处理。

public void batchCreate(List<String> originalUrls) { List<ShortLink> links = new ArrayList<>(); for (String url : originalUrls) { ShortLink link = new ShortLink(); link.setOriginalUrl(url); link.setShortCode(generateUniqueCode()); link.setCreateTime(LocalDateTime.now()); links.add(link); } // 分批插入，每批 500 条 for (int i = 0; i < links.size(); i += 500) { List<ShortLink> batch = links.subList(i, Math.min(i + 500, links.size())); shortLinkMapper.insertBatch(batch); } }

generateUniqueCode要保证不重复，用自增 ID 方案的话，得先插入拿到 ID 再更新短码，或者用 Redis 发号器。分批大小 500 是经验值，太大可能超过max_allowed_packet，太小又没效果。如果源码里没做批量，自己加一个insertBatch方法到 Mapper 里，XML 写<foreach collection="list" item="item" separator=",">就行。

4.3 修改跳转目标：缓存一致性问题

短链接允许随时修改跳转的原始 URL，这是刚需。但改了数据库后，如果 Redis 里还缓存着旧 URL，用户跳转就会到旧地址。解决办法是修改时删缓存，下次查询再回填。

public void updateOriginalUrl(String code, String newUrl) { shortLinkMapper.updateUrlByCode(code, newUrl); redisTemplate.delete("short_link:" + code); // 删缓存 }

这里有个坑：如果先删缓存再更新数据库，并发时可能读到旧数据又写回缓存。常见做法是「先更新数据库，再删缓存」，虽然理论上还有极小概率不一致，但对短链接场景够用了。如果源码里没处理缓存，改完 URL 后要等缓存自然过期才生效，测试时会以为没改成功。

5. 避坑与排查：启动失败、跳转异常和统计丢失

5.1 启动报Unknown column或Table doesn't exist

现象：mvn spring-boot:run后控制台抛 SQL 异常，提示字段或表不存在。原因：实体类字段和数据库表结构不一致，或者根本没建表。解决：对照实体类的@TableName和@TableField注解，逐字段核对数据库。MyBatis-Plus 默认开启驼峰转下划线，shortCode对应short_code，如果数据库字段名不对就会报错。建表时字段类型也要匹配，LocalDateTime对应datetime，Long对应bigint。

5.2 短链接跳转 404 或跳到了错误页面

现象：访问http://localhost:8080/abc123返回 404 或跳到notfound.html。原因有三种：短码在数据库里不存在、Controller 映射路径不对、或者前端路由拦截了。解决：先直接查数据库select * from short_link where short_code = 'abc123'，有数据就检查 Controller 的@GetMapping("/{code}")是否被其他映射覆盖。如果项目用了 Spring Security，匿名访问可能被拦截，需要在配置里放行/{code}路径。

5.3 访问统计数字不动或明显偏少

现象：跳转正常，但后台统计图表里访问量一直是 0 或远小于实际。原因：用了 301 重定向导致浏览器缓存、异步记录日志的线程池没生效、或者统计 SQL 的日期分组有时区问题。解决：确认重定向状态码是 302；检查@Async注解是否在启动类上加了@EnableAsync；统计 SQL 里DATE(access_time)要确认数据库时区和 Java 时区一致，否则跨天数据会算错。

5.4 批量创建时部分短码重复

现象：批量插入后，个别短码相同，跳转时指向了错误的原始 URL。原因：短码生成用了随机数但没做唯一性校验，或者自增 ID 方案在并发下拿了重复 ID。解决：数据库给short_code加唯一索引，插入时捕获DuplicateKeyException并重试。自增 ID 方案要确保 ID 由数据库生成，不要用应用层计数器。

5.5 前端npm install失败或启动后接口跨域

现象：npm install卡住或报ERESOLVE，前端启动后请求后端报 CORS 错误。原因：Node 版本和依赖不匹配，或者后端没配跨域。解决：看package.json里的engines字段，切到对应 Node 版本；跨域在后端加CorsConfig，允许localhost:前端端口的GET、POST请求。如果源码里已经带了跨域配置，检查allowedOrigins是否写死了某个端口。

6. 进阶技巧：把统计图表做准，把 AB 测试做稳

统计图表要准，核心在数据聚合的 SQL 和时区处理。我一般会在access_log表上按access_time建索引，然后统计查询用DATE_FORMAT(access_time, '%Y-%m-%d')分组。如果数据量大，每天凌晨跑定时任务把前一天的数据汇总到daily_stats表，图表直接查汇总表，避免每次扫全表。

-- 按天统计访问量 SELECT DATE_FORMAT(access_time, '%Y-%m-%d') AS day, COUNT(*) AS pv FROM access_log WHERE short_code = 'abc123' GROUP BY day ORDER BY day DESC; -- 按地区统计 SELECT region, COUNT(*) AS cnt FROM access_log WHERE short_code = 'abc123' GROUP BY region ORDER BY cnt DESC;

AB 测试要稳，关键是权重配置的持久化和分流的一致性。同一个用户多次访问同一个短码，最好每次都分到同一组，否则用户体验会割裂。做法是用 IP 或用户 ID 做哈希，对总权重取模，而不是纯随机。这样同一用户始终落在同一组，统计也更干净。

public String selectTargetSticky(String code, String userId) { List<AbTestConfig> configs = abTestMapper.selectByCode(code); int totalWeight = configs.stream().mapToInt(AbTestConfig::getWeight).sum(); int hash = Math.abs(userId.hashCode()) % totalWeight; int cumulative = 0; for (AbTestConfig config : configs) { cumulative += config.getWeight(); if (hash < cumulative) { return config.getTargetUrl(); } } return configs.get(0).getTargetUrl(); }

这段代码把随机数换成了userId.hashCode()，同一用户永远落在同一组。参数userId可以是 IP、设备 ID 或登录用户 ID，看业务能拿到什么。如果源码里用的是纯随机，改成这个粘性分流只需要替换一行。

最后说个血泪经验：短链接系统上线前，一定要用压测工具跑一遍跳转接口，看异步日志记录会不会把线程池打满。我见过一个系统，跳转本身很快，但访问日志同步写库，QPS 一过 500 就雪崩。从那以后我每次拿到这类源码，都先确认日志记录是不是异步的，不是就自己加@Async和线程池配置。希望帮到你。

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