Java注解学习关键在于分类逻辑、使用场景与框架边界:ORM映射注解(如@TableId)仅用于持久层;数据校验注解(如@NotNull)依赖@Valid触发于Controller/Service;工具增强注解(如@Excel、@Data)属框架专属,互不干扰。

按用途分三类,先立主干
ORM 映射注解(如 @TableId、@TableName)——只在数据持久层生效,和数据库表字段打交道,不参与 Excel 或校验。
数据校验注解(如 @NotNull、@Email)——属于 Bean Validation 规范,运行在 Controller 入参或 Service 方法参数上,依赖 @Valid 或 @Validated 触发。
工具增强注解(如 EasyPoi 的 @Excel、Lombok 的 @Data)——框架专属,各管一摊:@Excel 只在导出/导入时起作用,@Data 编译期生成代码,彼此不交叉,也不影响 ORM 或校验流程。
看框架再选注解,别混用
同一个功能,不同框架有不同实现:
• 主键生成?MyBatis-Plus 用 @TableId(type = IdType.ASSIGN_ID),JPA 用 @GeneratedValue(strategy = GenerationType.IDENTITY) ——不能通用。
• 逻辑删除?MP 推荐 @TableLogic,JPA 要配合 @Where 或自定义 Repository。
• Excel 列绑定?EasyPoi 用 @Excel(fixedIndex = 2),Apache POI 原生则需手动遍历 Cell ——前者省代码,后者更可控。
记住:注解的生命力来自它所依附的框架处理器。没引入对应 starter 或没启用对应 AutoConfiguration,注解就是普通元数据,毫无作用。
查文档比记属性更重要
像 @Excel 的 replace、suffix、needMerge 这些属性,不用死记;遇到需求时,打开 EasyPoi 官方 GitHub 搜 “@Excel”,5 秒内定位示例;
同理,校验注解去 Bean Validation 官网 查约束列表,MyBatis-Plus 注解去 官方文档 ORM 章节 找最新支持项。
真正高频需要记住的只有几个骨架:
• @TableId + @TableName(MP 必用)
• @NotNull + @Size(校验最常用)
• @Excel + @ExcelCollection(EasyPoi 导入导出核心)
动手验证比读十遍更有效
写一个极简测试类,三步闭环:
• 定义实体类,加 1~2 个典型注解
• 在对应场景调用(如用 ExcelExportUtil.exportExcel() 触发 @Excel,用 validator.validate() 触发校验注解)
• 故意填错数据或删掉必要注解,观察控制台报什么错、哪里断点进不去
这样一次实操,胜过扫十页文档。


















