apt不生成孤立变量，而是生成含静态常量/构建字段/预设实例的完整类，如networkconfig；其本质是编译期通过注解驱动创建语法合法、可封装复用的辅助源文件。
java注解处理器（apt）本身不基于oop思想“实现变量生成”，它是一个编译时元数据处理机制，核心是扫描注解、分析元素、生成新源码——生成的不是“变量”，而是类、方法、字段等完整结构。所谓“编译时变量生成”，实际是指：通过注解标记意图，由apt在编译期自动创建包含特定字段（如常量、配置值、上下文对象）的辅助类，这些字段在语义上承担了“可复用变量”的职责。
明确目标：什么是“变量生成”的真实含义
开发中常说的“生成变量”，通常指以下三类典型场景：
- 为配置类自动生成带默认值的公共静态常量字段（如 API_BASE_URL、TIMEOUT_MS）
- 为领域模型类生成不可变的构建上下文类（Builder），其中每个字段对应原始类的一个属性，天然具备“中间状态变量”语义
- 为模块定义统一入口，生成含预设实例的工具类（如 ServiceHolder.INSTANCE），避免重复 new 或查找
这些都不是运行时动态分配变量，而是把本该手写的、结构固定的字段声明，交由编译器在 javac 阶段一次性生成，保证一致性与零反射开销。
关键实现步骤：从注解到字段声明
以生成静态常量字段为例，需完成四步闭环：
-
定义源码级注解：使用
@Retention(RetentionPolicy.SOURCE)，限定仅参与编译，不进入字节码；用@Target(ElementType.TYPE)表明作用于类 -
编写处理器逻辑：继承
AbstractProcessor，在process()中遍历被注解的TypeElement，提取类名、包名及期望的常量信息（可通过注解属性传入，如@ConfigVars(base = "https://api.example.com")） -
构造字段节点：用 JavaPoet 创建
FieldSpec，设置修饰符public static final、类型（如String.class）、名称（如"API_BASE_URL"）和初始值（如LiteralConstant("https://api.example.com")） -
写入新类文件：调用
Filer.createSourceFile()创建Constants.java，将所有字段注入TypeSpec并输出
为什么不能直接“生成变量”而必须生成类
APT 的设计约束决定了它无法向现有类注入成员——它只能创建全新的 .java 源文件。这是因为：
- javac 编译流程是单向的：先解析源码 → 再执行处理器 → 最后统一编译所有源文件（含生成的）
- 处理器拿到的是只读的
Element抽象视图，不提供修改 AST 或字节码的能力（那是 Lombok 等借助编译器内部 API 实现的高级操作） - 所有生成代码必须符合 Java 语法规范，独立可编译；孤立的“变量声明”没有所属作用域，语法非法
所以，“变量生成”本质是封装：把一组语义相关的常量/实例收拢进一个命名清晰的类中，例如 NetworkConfig 或 AppConstants，使用者通过类名即可访问，符合面向对象的封装原则。
实用建议：让生成更贴近OOP习惯
要使生成结果具备良好OOP特性，注意三点：
- 字段命名采用大驼峰 + 全大写风格（如
DEFAULT_RETRY_COUNT），并添加 Javadoc 注释说明用途和取值范围 - 为生成类添加
private构造方法，防止被实例化，强调其工具类定位 - 若需多组变量，支持注解嵌套或数组属性（如
@ConfigVar(name="DB_URL", value="jdbc:h2:mem:test")），让一个注解驱动多个字段生成
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
