自我介绍

您好，我是 xxx，2026 届软件工程专业应届生，主要方向是 Java 后端开发，熟悉Spring Boot、MyBatis、Redis等技术栈。

在项目经验方面，在音乐系统中，我针对接口被恶意刷取的问题设计防刷机制。包括在登录注册、评论等关键操作接口加入图形验证码校验，同时结合 Redis 对请求频率进行限制，通过记录用户或 IP 的访问次数来控制单位时间内的请求上限，防止接口被滥用。

我对技术比较感兴趣，平时会阅读技术博客，能够较快理解并应用所学到的新知识。

对于薪资

我作为一个应届生，目前更看重的是发展的平台和机会，对薪资没有特别硬性的要求，在此要再次感谢公司对我能力的认可。至于薪酬，我相信公司一定有一个公平合理的薪酬体系，能按照公司的薪资标准来就行了。

对于加班

可以接受加班。(也能理解项目情况有时候会很忙，这时候就可能需要加班。同时我也会思考是不是因为自己的工作能力是不是还不足)

防刷怎么实现

我主要做了两层控制：
第一层是验证码校验，防止自动化脚本直接调用接口。
第二层是基于 Redis 的限流机制，例如通过 key 记录某个用户或 IP 在单位时间内的请求次数，超过阈值则拒绝请求或短时间封禁。

验证码的实现

数字：后端生成随机字符串作为验证码，并存入 Redis 设置过期时间。使用 Java 的图形绘制 API 将字符串绘制成图片，并添加干扰线和噪点增强安全性。前端提交验证码时，后端从 Redis 取出进行校验，校验成功后删除缓存。

滑块：后端随机生成一个滑块缺口位置，并根据背景图裁剪出拼图块，同时将真实的目标 x 坐标存入 Redis 并设置过期时间。 前端用户拖动滑块后提交滑动距离，后端判断滑动距离与真实坐标的误差是否在允许范围内，如果匹配则验证通过，并删除 Redis 中的记录防止重复使用。

文字验证码

在校期间，我主导开发了一个基于 Spring Boot 的分布式音乐管理平台——Echo Music Server 。这个项目不仅是一个简单的 CRUD 系统，更是一个我用来实践高可用架构和工程化思维的完整作品。

在 系统设计 层面，我并没有采用传统的单体大泥球架构，而是基于领域驱动设计（DDD）的思想，严格划分了 Controller、Service、Mapper 三层架构，并强制分离了 DTO（数据传输对象） 、 VO（视图对象） 和 Entity（数据库实体） ，以此来保证系统的可维护性和扩展性。

在 性能与存储 方面，考虑到音乐平台的核心挑战是 海量大文件的存储与高频访问 ：

  1. 存储解耦 ：我引入了 MinIO 对象存储 来替代传统的本地文件存储。这不仅解决了应用服务器的磁盘 I/O 瓶颈，还实现了 应用服务与文件服务的解耦 ，为未来系统的横向扩展打下了基础。

  2. 会话管理 ：针对高并发下的用户认证，我采用了 JWT + Redis 的无状态认证方案。利用 Redis 存储 Token 的黑名单和用户上下文，既保证了接口的响应速度，又解决了 JWT 难以强制登出的安全痛点。
    在 稳定性与故障预案 方面，我特别关注系统的 健壮性 ：

  3. 资源泄露防护 ：在实现音频元数据解析（如时长提取）时，我集成了 JAVE 组件。为了防止临时文件堆积导致服务器磁盘爆满，我设计了严格的 临时文件生命周期管理 机制，利用 try-finally 块确保每一份临时文件在解析完成后都能被物理删除。

  4. 容错机制 ：在涉及文件删除的业务中（如删除歌曲），我设计了 容错逻辑 。即使 MinIO 中的文件因网络抖动删除失败，系统也会捕获异常并记录错误日志，确保数据库层面的元数据一致性，避免因文件服务异常导致整个事务回滚。

  5. 全链路监控 ：为了提升系统的可观测性，我利用 Spring AOP 实现了非侵入式的 操作日志审计 ，将日志逻辑与业务逻辑完全解耦，能够记录每个关键操作的耗时、参数与结果，为后续的性能优化和故障排查提供了数据支持。
    通过这个项目，我最大的收获是从 全局视角 去思考问题： 代码不仅要能跑通，更要考虑在高并发、网络异常等极端情况下的表现 。我希望能够加入贵团队，在真实的业务场景中继续打磨我的工程能力。