一套提升 Spring Boot 项目的高并发、高可用能力的 Cursor 专用提示词

一套**「工程级、可控、不翻车」的 Cursor 专用提示词**，专门用于：

在不破坏核心逻辑 & API 规范的前提下，提升 Spring Boot 项目的高并发、高可用能力

一、使用前的"正确姿势"（很重要，先看）

在 Cursor 里：

打开项目根目录
模型选择：
- 第一次分析：👉 Claude Opus
- 后续局部优化：👉 Claude Sonnet
第一次一定只让它"分析"，不要直接改代码

二、第一阶段：系统级分析 Prompt（必做）

👉 先用这个 【只分析，不改代码】 的提示词：

复制代码

你现在是一名资深 Java 后端架构师，擅长高并发与高可用系统设计。

请先不要修改任何代码，仅基于当前 Spring Boot 项目进行分析，重点关注：
1. 在高并发场景下可能存在的瓶颈（线程、锁、IO、数据库、缓存）
2. 是否存在潜在的并发安全问题（共享状态、静态变量、非线程安全组件）
3. 在高可用层面存在的风险（单点、超时、重试、降级、熔断缺失等）
4. 事务使用是否可能在高并发下放大性能问题
5. 接口层是否存在可能被恶意或突发流量击穿的风险

请：
- 按「严重程度」排序问题
- 标注涉及的模块 / 类
- 给出"优化思路"，不要直接给代码

📌 这一步的目标：

判断 Claude 是否真的"懂并发"
你先当 Reviewer

三、第二阶段：制定"安全改造范围"（关键防翻车）

分析结束后，用这个 Prompt 框住它的手 👇

复制代码

接下来我们将对项目做高并发 / 高可用方向的改造，请严格遵守以下约束：

1. 不允许修改任何对外 API 的：
   - URL
   - 请求 / 响应结构
   - 语义行为
2. 不允许改变核心业务逻辑与业务规则
3. 不允许引入破坏性架构调整（如大规模重写）
4. 所有改造必须是：
   - 可逐步上线
   - 可回滚
5. 优先使用 Spring Boot / Java 生态的成熟方案

在这个前提下，请给出一个【分阶段改造方案】，每个阶段说明：
- 目标
- 涉及模块
- 风险点
- 回滚方式

📌 这一步：

直接把 AI 拉回"工程现实"

四、第三阶段：逐点落地改造 Prompt（最常用）

当你选定某一项（比如线程池、缓存、限流）后，用下面的模板。

示例 1：线程池 / 异步改造

复制代码

请针对当前项目的线程使用情况进行优化，重点关注：
1. 是否存在使用默认线程池的风险
2. 是否存在阻塞操作占用业务线程的问题
3. 线程池参数是否适合高并发场景

在不改变现有业务逻辑的前提下：
- 建议合理的线程池拆分方案
- 明确每个线程池的使用场景
- 给出代码级改造建议（可生成 diff）

示例 2：接口限流 / 保护

复制代码

请分析当前 Controller 层接口在高并发或突发流量下的风险。

在不修改接口定义和业务语义的前提下：
1. 建议合适的限流策略（如本地限流、分布式限流）
2. 说明限流粒度与位置（Controller / Service）
3. 给出可配置、可开关的实现方式
4. 不要影响正常用户体验

请先给设计思路，再给代码改造示例

示例 3：数据库与事务优化

复制代码

请分析当前 Service 层事务使用情况，在高并发场景下是否存在：
- 事务范围过大
- 读写混用
- 不必要的事务嵌套

在不改变业务行为的前提下：
- 给出事务收敛与优化建议
- 指出可以安全拆分或下沉的点
- 生成最小改动的代码 diff

五、第四阶段：让 Claude 自己"做风险自检"（高级技巧）

这是很多人不知道的用法👇

复制代码

请你以 Code Review 的视角，审查刚才提出的高并发 / 高可用改造方案，重点检查：
1. 是否存在过度设计
2. 是否引入新的并发风险
3. 是否可能影响现有接口语义
4. 在真实生产环境中可能踩的坑

请指出你最不放心的 3 个地方

📌 这一步：

用 AI 打 AI

六、一个"总控 Prompt"（可以长期复用）

可以把下面这个存成 Cursor Snippet：

复制代码

你是资深 Java 架构师。
目标：在不影响核心业务逻辑和现有 API 规范的前提下，
提升 Spring Boot 项目的高并发与高可用能力。

约束：
- 不改对外接口
- 不改业务语义
- 改造必须可回滚
- 优先最小侵入方案

流程：
1. 先分析问题（不改代码）
2. 给分阶段方案
3. 单点改造时先给思路再给 diff
4. 每次改造后自检风险

请严格按上述流程执行。

七、一句很重要的话

真正的高手用 AI，不是让它"放开改"，而是"被约束地改"