Spring生态组件选型与实践需把握核心要点：IOC优先使用构造器注入和三级缓存解决循环依赖，避免getBean滥用；AOP推行面向接口编程需处理自调用和异常回滚规则，注意切面不过度侵入；安全防护建议新项目采用Spring Security（需关闭默认CSRF）并校验密码编码器强度，旧系统维护时注意Shiro的RememberMe密钥防护和权限缓存更新效率；模板引擎Thymeleaf适用于后台管理场景，需防范XSS风险和模板与业务LOGO解耦；云原生选型SCK（K8s原生服务架构）更适合新建云原生项目，SCA（兼容DUBBO/阿里云栈）适用存量改造，混用时需解决双服务发现冲突；AI接入应整合ChatModel与Advisor，严格校验函数调用参数并做单元测试，避免密钥硬编码。各组件选择需对齐业务场景：新项目优先Spring体系，旧系统需评估升级成本和兼容度，云原生项目若已构建IMDS和SPIFFE体系可跳过独立服务注册中心建设。

微服务组件选型需结合技术栈与运维能力：Consul适合跨语言、跨机房场景，提供的服务发现、KV配置及DNS解耦能力完整；Nacos凭借与Spring Cloud生态的深度整合更适配现有体系，支持动态路由和灰度发布。配置中心选择需考虑团队现有架构：Apollo在多环境灰度审计场景更具优势，Nacos的配置管理则与注册发现天生耦合。客户端容错方案推荐resilience4j的新架构，其装饰器模式灵活且不强制线程池隔离，与Hystrix互补使用需注意状态迁移和降级逻辑的差异。网关应对入口流量治理，需明确路由与过滤的职责边界，避免将业务容错逻辑注入。容器化场景优先采用Spring Cloud Kubernetes，需注意RBAC权限设置和滚动发布的就绪探针控制点，同时与Service Mesh网关明确职责分工。选型矩阵建议按业务规模与技术栈成熟度动态评估，优先验证现有组件兼容性，避免盲目迁移带来的订单系统级风险。

【IT老齐842】Spring Cloud 2025微服务技术选型推荐_哔哩哔哩_bilibili