代理模式无法强制校验线程必须调用start()，因thread.start()是native方法，不可被jdk动态代理或cglib拦截；真正有效的是封装线程工厂、静态代码扫描和字节码校验等设计契约手段。
不能通过代理模式“强行校验线程启动必须调用 start()”——这不是代理模式的适用场景，也不是技术上可行的设计。
线程启动机制本身不支持代理拦截
Java 中 Thread.start() 是一个本地（native）方法，最终由 JVM 底层调度，无法被 Java 层的代理（如 JDK 动态代理、CGLIB）拦截或增强。即使你对 Thread 实例做了代理：
- 代理对象调用 start() 时，实际仍是原 Thread 对象执行 native 方法，代理逻辑无法插入校验点
- 若重写 run()，那只是覆盖任务体，和是否调用 start() 完全无关
- 直接调用 run() 不会开启新线程，这是 JVM 规范行为，代理无法阻止用户写出
thread.run()
真正可控的入口是线程创建与使用规范
企业脚手架中要约束“必须用 start() 启动”，靠的是设计契约 + 编译期/运行期防护，而非代理：
-
封装线程工厂：提供
ThreadFactory或TaskExecutor统一入口，禁止直接 new Thread；所有任务走 submit() 或 execute() -
静态代码扫描：用 SonarQube 或自定义 Checkstyle 规则，检测源码中出现
.run()调用且接收者为 Thread 类型，直接报错 -
ClassLoader 级拦截（高级）：在自定义类加载器中，对字节码做校验——若发现某类中存在
invokevirtual Thread.run且非在 Thread 子类内部调用，抛出VerifyError
强制代理模式在这里会误导设计方向
代理模式适用于行为增强（如日志、权限、事务），前提是目标方法可被拦截。而 start() 不可代理，强行套用“强制代理”概念，只会导致：
- 用私有字段标记“是否已代理”，但无法阻止用户绕过代理直接操作原始 Thread 实例
- 在 run() 开头加校验逻辑（比如检查调用栈是否有 start），但该检查本身可被跳过，且性能损耗明显
- 混淆关注点：线程生命周期管理应由调度器/执行器负责，不是代理该管的事
脚手架真正该做的是统一抽象并发模型——比如只暴露 AsyncTask 接口，内部强制走 ThreadPoolExecutor.submit()，从源头消灭裸 Thread 的使用可能。
