可重复注解提升的是代码可读性、维护性和语义表达力，而非运行时性能；它以独立、自包含的注解行替代嵌套数组，降低心智负担，简化增删操作，并获得IDE更细粒度的支持。
可重复注解本身并不直接提升运行时性能，它的优势集中在**代码可读性、维护性和语义表达力**上，而非执行效率。所谓“比传统数组传值方式更具备可读性”，关键在于它把“多个同类型配置项”的意图，用自然、贴近业务的语言直白地写在代码里，而不是藏在一个数组参数中。
语义更清晰：每个注解独立表达一个含义
传统方式常把多个同类配置塞进一个注解的数组属性里，比如：
@ApiResponses({
@ApiResponse(code = 200, message = "成功"),
@ApiResponse(code = 404, message = "未找到")
})
这看起来像是一次性声明一组响应，但实际阅读时需先识别出@ApiResponse是嵌套结构，再逐个看数组元素——心智负担略重。而可重复注解允许你直接写成：
@ApiResponse(code = 200, message = "成功") @ApiResponse(code = 404, message = "未找到")
每一行都是一个完整、自包含的语义单元，和文档列表一样直观，无需括号和逗号分隔，也无需关注“这是第几个元素”。
编辑与维护更轻量
当需要增删某个响应时：
- 用数组方式：得打开大括号，定位到数组内部，手动加逗号、处理末尾逗号、注意引号配对；稍不注意就语法报错。
- 用可重复注解：光标移到任意位置回车，直接粘贴一行新注解即可；删掉某一行也不会影响其他行——就像删一段 Markdown 列表项那样自然。
工具支持更友好
IDE（如 IntelliJ）对可重复注解有专门识别：
- 悬停提示能单独展示每一条注解的含义；
- 重构时可单独重命名某一个注解的参数，不影响其余；
- 代码补全会按顺序建议每个
@ApiResponse，而不是跳进数组里补全整个@ApiResponses容器。
这种粒度更细的支持，让日常编码节奏更顺滑。
不等于放弃数组，而是分层设计更合理
可重复注解不是取代数组，而是把“容器逻辑”下沉到编译器层面。开发者专注表达“我需要两个响应”，而不是“我要构造一个 ApiResponse 数组并赋给 value 字段”。底层仍通过容器注解（如 @ApiResponses）承载数组，但这一层对日常开发透明——既保留了 JVM 注解模型的兼容性，又解放了上层表达。
