装饰器模式本身不提供日志过滤能力，它只负责包装和转发；真正实现过滤逻辑的必须是内部嵌套的判断分支或外部注入的Filter实例。
装饰器模式加日志过滤的核心限制在哪
装饰器模式本身不提供日志过滤能力，它只负责「包装」和「转发」；真正实现过滤逻辑的必须是内部嵌套的判断分支或外部注入的 Filter 实例。强行在装饰器里硬编码 if-else 判断日志内容，会导致职责混杂、难以复用，也违背开闭原则。
所以关键不是“用装饰器做过滤”，而是“用装饰器把日志记录器和过滤器组装起来”。常见错误是把 filter_dict 直接塞进 logger.info() 调用却没配好 Filter 类，结果 extra 参数完全被忽略。
- Python 中必须继承
logging.Filter并重写filter()方法，且该实例需显式添加到Handler上 - Java 里若用 JDK 动态代理，
InvocationHandler.invoke()中可插入条件判断，但不宜处理复杂日志规则——应交给专门的LogFilter或 AOP 切点表达式 - Spring AOP 场景下，
@Around比@Before更适合做日志过滤，因为能控制是否放行原方法调用
Python logging 中让 extra 参数触发双输出的实操要点
目标是：仅当某条日志带 extra={'to_console': True} 时，才额外打印到 sys.stdout，其余日志照常写文件。这不能靠修改 Logger 级别或全局配置，必须依赖 Filter + 多 Handler 协同。
典型错误是只给 StreamHandler 加了 ContextFilter，但没在 filter() 方法里检查 record.__dict__.get('to_console') —— 这个字段只存在于带 extra=... 的那条日志中，普通日志 record 里根本没有它。
- 定义过滤器时，用
hasattr(record, 'to_console')或更稳妥的getattr(record, 'to_console', False) - 确保
StreamHandler和FileHandler是两个独立实例，且各自绑定对应的Filter - 不要在
filter()里 print 或调用logger.xxx()，否则会递归触发自身
class ToConsoleFilter(logging.Filter):
def filter(self, record):
return getattr(record, 'to_console', False)
console_handler = logging.StreamHandler()
console_handler.addFilter(ToConsoleFilter())
Java 动态代理做日志增强时怎么安全加过滤条件
在 CustomInvocationHandler.invoke() 里直接写 if (method.getName().equals("log")) {...} 是脆弱的：一旦目标类方法签名变化或新增日志方法，就得改代理逻辑。更合理的方式是把过滤决策外移到策略对象中。
比如提取一个 LogFilterStrategy 接口，实现类根据注解（如 @Loggable(level = "DEBUG")）、方法名正则、甚至参数类型动态决定是否记录。代理层只负责调用策略，不掺和具体规则。
- 避免在
invoke()中做耗时操作（如 IO、远程调用），否则拖慢所有被代理方法 - 注意
method.invoke(target, args)抛出的是InvocationTargetException，需用e.getCause()获取原始异常 - 如果目标类没有实现接口，JDK 代理会失败，此时必须切到 CGLIB，但 CGLIB 无法代理
final类或方法
Spring AOP + 自定义注解实现按需日志过滤的最小闭环
比起手动写代理或装饰器，Spring AOP 是更贴近“不改原类”的标准解法。但很多人卡在注解没生效——根本原因是没开启 @EnableAspectJAutoProxy，或切点表达式写错导致目标方法根本没被拦截。
最简可行路径是：定义注解 → 写切面类 → 配置切点 → 在业务方法上加注解。其中切点表达式 @annotation(com.example.LogIf) 必须和注解全限定名严格一致，大小写都不能错。
- 注解需声明
@Retention(RetentionPolicy.RUNTIME)，否则运行时拿不到 - 切面类方法参数用
JoinPoint joinPoint可获取方法签名和参数，用ProceedingJoinPoint pjp才能控制是否执行原方法 - 若想根据参数值过滤（如只对
userId > 1000的请求记日志），必须用@Around，并在pjp.proceed()前后加判断
装饰器模式或代理机制只是手段，真正的过滤能力来自你如何组织条件判断的位置和粒度。越靠近日志落地前的环节（如 Handler / Appender 层）做过滤，越稳定；越往调用链上游（如 Controller 层）做判断，越容易漏掉异步或间接调用的日志。
