必须用自定义Checkstyle规则强制拦截接口中非法的非public方法声明，因其违反JLS §9.4；需检查private、protected、final等修饰符，排除static/default内部private，并在IDE实时高亮、CI构建硬阻断。
接口中声明 非 public 方法（如 private、protected、包级默认权限）属于 Java 语言规范明确禁止的行为，编译器本应直接报错。但某些场景下（如使用 Lombok 的 @Builder 或误用注解处理器、IDE 缓存异常、旧版 JDK 兼容模式），这类非法声明可能绕过编译检查，或在 IDE 中仅以弱提示呈现，导致问题潜入代码库。要真正“强制拦截”，必须依赖静态走查工具在编译前精准识别并阻断。
明确识别目标：哪些声明算违规
静态检查需覆盖所有违反 JLS §9.4（接口方法修饰符约束）的写法：
-
interface Service { void doWork(); }—— 合法，默认public abstract -
interface Service { private void helper() { } }—— 违规，Java 9+ 接口支持private方法，但仅限 static 或 default 方法体内部；独立声明的private方法非法 -
interface Service { protected String getName(); }—— 违规，protected在接口中无意义且不被允许 -
interface Service { final void commit() { } }—— 违规，final与抽象方法冲突，且接口方法不可为final -
interface Service { static void run() { } }—— 合法（Java 8+），但若缺失public修饰符，仍属隐式public，不违规；重点在于 显式使用非 public 修饰符
用自定义 Checkstyle 规则实现编译前硬拦截
标准 Checkstyle 不校验接口方法修饰符合法性，需编写自定义检查器，继承 AbstractCheck，监听 METHOD_DEF AST 节点：
- 定位节点父级是否为
INTERFACE_DEF（确认在接口内） - 提取该方法的所有修饰符（
MODIFIERS子节点） - 检查是否存在
private、protected、package（即无修饰符但非public）、final、native、synchronized等非法修饰符 - 若存在，立即调用
log(...)并设为SeverityLevel.ERROR，确保 Maven/Gradle 构建失败 - 排除
static和default方法中的private工具方法（需沿 AST 向上判断是否在STATIC_INIT或DEFAULT_METHOD节点内）
IntelliJ IDEA 中实时高亮与快速修复
仅靠构建拦截不够，开发阶段就要暴露问题：
- 在 IDEA 中安装 CheckStyle-IDEA 插件，导入上述自定义规则 XML 配置
- 启用 “Scan on the fly”（实时扫描），违规方法名将标红波浪线，悬停显示错误信息
- 光标置于违规行，按
Alt + Enter，选择 “Remove illegal modifier” 快速清除private/protected等冗余关键字 - 若误写为包级访问（无任何修饰符），插件可自动补全
public，避免手动遗漏
配套 CI 流程加固防线
本地和 IDE 检查可能被绕过，CI 环节必须二次确认：
- 在
pom.xml或build.gradle中配置 Checkstyle 插件，绑定到compile或verify生命周期 - 设置
failOnViolation = true，任一违规即中断构建 - 将检查结果生成 HTML 报告，上传至流水线归档，供质量门禁审计
- 配合 SpotBugs 或 ErrorProne 做交叉验证（虽不主查此问题，但部分扩展规则可辅助发现修饰符矛盾）
不复杂但容易忽略——接口方法权限不是风格问题，是语法红线。用自定义静态规则把它变成编译不过的硬门槛，比等 PR 评审时才发现更可靠。
