1. 这不是背题手册，而是一份Spring Boot面试现场的“技术复盘报告”

我带过37个校招新人，也给21家不同规模的公司做过技术终面，每次问Spring Boot，90%的候选人一上来就背“自动配置原理”“起步依赖作用”，但只要我追问一句：“你项目里那个 @ConfigurationProperties 绑定的配置类，如果YAML里写错了缩进，Spring Boot是报错还是静默忽略？报错堆栈里哪一行才是真正的根因？”，一半人当场卡壳。这不是考记忆力，是考你有没有真正把Spring Boot当成一个活的、有脾气的框架来相处过。今天这篇，不列100道题，只拆解5个真实面试中高频出现、但几乎没人能答全的技术切口—— 自动配置的加载时机与失效边界、条件化Bean的嵌套判定逻辑、Actuator端点在生产环境的真实权限陷阱、多模块Maven依赖传递时的版本撕裂现象、以及PDF模板填充场景下iText7与Spring Boot生命周期的隐式冲突 。这些不是知识点，而是你在IDEA里调试过、在服务器上重启过、在日志里逐行grep过的实战痕迹。如果你只用过 @SpringBootApplication 启动一个CRUD服务，那建议先去本地跑一遍 spring-boot-starter-web 的源码断点；如果你已经用Spring Boot搭过支付对账系统或批量导出平台，你会发现，所谓“面试题”，不过是把线上问题提前搬进了会议室。关键词：Spring Boot、Interview Questions——它们不是考试范围，而是你工程能力的刻度尺。

2. 自动配置的真相：它不是魔法，而是一场精密的“条件谈判”

2.1 Spring Boot自动配置的三重门：类路径、条件注解、配置属性

很多人以为 @EnableAutoConfiguration 就是“扫描所有starter然后一股脑注入Bean”，这是最大的误解。Spring Boot的自动配置本质是一场分阶段的条件谈判，共设三道门禁：

第一道门：类路径存在性（Classpath Condition）
Spring Boot不会无差别加载所有 spring-boot-autoconfigure 包里的 *AutoConfiguration 类。它先通过 spring.factories 文件读取 org.springframework.boot.autoconfigure.EnableAutoConfiguration 键下的全限定名列表，再逐个检查这些类是否在当前类路径（classpath）中存在。比如 DataSourceAutoConfiguration 类里有 @ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class }) ，如果项目没引入 spring-jdbc 或 HikariCP ，这个类根本不会被加载到JVM，更谈不上后续判断。我见过最典型的误操作：在 pom.xml 里把 spring-boot-starter-jdbc 的scope设为 test ，结果本地单元测试能跑通，但打包部署后 DataSource Bean死活不出现——因为生产环境的类路径里压根没有 DataSource.class 。

第二道门：条件注解的嵌套判定（Nested Conditional Logic）
@ConditionalOnMissingBean 不是简单的“没有就创建”，它会触发深度反射扫描。以 WebMvcAutoConfiguration 为例，它内部嵌套了：

@ConditionalOnMissingBean(value = ViewResolver.class, search = SearchStrategy.CURRENT)
@ConditionalOnMissingBean(BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
    applicationContext, ViewResolver.class, true, false).length == 0)

注意第二个条件里的 search = SearchStrategy.CURRENT ——它只查当前 ApplicationContext ，不向上级容器（如父 ApplicationContext ）查找。这意味着如果你在 @Configuration 类里手动定义了一个 InternalResourceViewResolver ，但把它注册到了父容器（比如通过 @Import 引入的另一个配置类）， WebMvcAutoConfiguration 依然会生效，导致两个 ViewResolver 冲突。实测下来，这种跨容器的Bean注册是线上404错误的隐形推手，排查时得用 applicationContext.getBeanNamesForType(ViewResolver.class) 逐层打印。

第三道门：配置属性的动态开关（Property-Driven Toggle）
spring.autoconfigure.exclude 参数常被当作“一键关闭所有自动配置”的银弹，但它有致命缺陷：它只能排除 spring.factories 里声明的顶层 *AutoConfiguration 类，无法影响这些类内部通过 @ConditionalOnProperty 控制的子模块。比如 spring.redis.host 配置错误时， RedisAutoConfiguration 会因 @ConditionalOnClass(RedisConnectionFactory.class) 失败而整体跳过，但 LettuceConnectionConfiguration （它在 RedisAutoConfiguration 内部）的 @ConditionalOnProperty(name = "spring.redis.lettuce.shutdown-timeout") 判断却可能已执行过——这就造成部分Redis相关Bean被创建、部分未创建的“半残”状态。我在某电商大促前夜就遇到过：运维改了 application.yml 里的 spring.redis.timeout=0 （本意是禁用超时），结果 LettuceClientConfigurationBuilderCustomizer 因 @ConditionalOnProperty 判定为true而初始化，但底层连接池却因timeout=0直接拒绝创建连接，整个缓存层雪崩。

提示：验证自动配置是否生效，别只看 /actuator/conditions 端点。它只显示顶层 *AutoConfiguration 类的匹配结果。要查具体Bean，用 applicationContext.getBeansOfType(YourTargetClass.class) 并遍历 BeanDefinition 的 getOriginatingBeanDefinition() 方法，才能看到是哪个 @Configuration 类最终生成了它。

2.2 @SpringBootApplication 的隐藏契约： @ComponentScan 的扫描盲区

@SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan ，但 @ComponentScan 默认只扫当前包及其子包。这在单模块项目里没问题，可一旦进入多模块场景，问题就来了。假设你的项目结构是：

parent/
├── common/          # 工具类、通用DTO
├── api/             # Controller层，含@SpringBootApplication
└── service/         # Service实现，含@Service注解

如果 api 模块的启动类在 com.example.api.Application ，而 service 模块的 OrderService 在 com.example.service 包下， @ComponentScan 默认不会扫描 com.example.service —— OrderService Bean永远不会被创建。解决方案只有两个：

  1. 显式指定扫描路径 ： @SpringBootApplication(scanBasePackages = {"com.example.api", "com.example.service"}) ；
  2. 利用Maven依赖传递 ：让 api 模块 <dependency> 引入 service 模块，同时在 service 模块的 pom.xml 里添加 <packaging>jar</packaging> ，确保其 classes 目录被加入 api 模块的类路径。

我踩过的坑是第二种方案里漏了 <packaging> 标签—— service 模块被打成了 pom 包， api 模块编译时根本看不到它的字节码， @ComponentScan 自然扫不到。这种错误在IDEA里甚至不报红，因为Maven依赖树显示正常，但运行时 NoSuchBeanDefinitionException 直接炸开。

2.3 条件化Bean的“时间差”陷阱： @PostConstruct 与 @EventListener 的执行顺序

@ConditionalOnBean 和 @ConditionalOnMissingBean 的判定发生在Spring容器的 BeanFactoryPostProcessor 阶段，而 @PostConstruct 方法执行在 InitializingBean.afterPropertiesSet() 之后、 SmartInitializingSingleton.afterSingletonsInstantiated() 之前。这意味着：

  • 如果你在一个 @Configuration 类里定义了 @Bean A，并用 @ConditionalOnMissingBean 保护；
  • 又在另一个 @Configuration 类里定义了 @Bean B，它依赖A，且B的 @PostConstruct 方法里调用了A的某个方法；
  • 那么当A因条件不满足而未创建时，B的 @PostConstruct 会在A不存在的情况下被调用，抛出 NullPointerException 。

更隐蔽的是 @EventListener 。 @EventListener 监听的事件（如 ApplicationReadyEvent ）在所有单例Bean初始化完成后才发布，但 @ConditionalOnBean(SomeService.class) 的判定早已完成。所以如果你在 @EventListener 方法里试图获取 SomeService ，而它因条件不满足未创建，这里就会报 NoSuchBeanDefinitionException 。解决办法是：在 @EventListener 方法参数里加 @Nullable ，或用 applicationContext.getBeanProvider(SomeService.class).getObject() 安全获取。

注意： @ConditionalOnBean 默认 search = SearchStrategy.ALL ，会向上级容器查找。如果你的 SomeService 定义在父容器（比如Spring Cloud Config Server的上下文），子容器的 @ConditionalOnBean 依然能匹配成功——这常导致本地开发环境正常、K8s集群里却失效的诡异问题。

3. Actuator端点的生产级权限设计：别让 /actuator/env 成为你的数据泄露口

3.1 默认端点暴露的“蜜罐效应”：为什么 /actuator/health 比 /actuator/env 更危险

Spring Boot 2.x默认只暴露 /actuator/health 和 /actuator/info ，但很多团队为了“方便监控”会把 management.endpoints.web.exposure.include=* 写进 application.yml 。这看似省事，实则埋下三颗雷：

第一颗雷： /actuator/env 暴露全部配置源
它不仅返回 application.yml 里的内容，还会列出 System.getProperties() 、 System.getenv() 、 ConfigurableEnvironment 里所有 PropertySource 。我审计过一个金融客户的生产环境： /actuator/env 返回了 systemProperties 里明文的 user.home=/home/appuser ，结合 /actuator/heapdump 下载的堆转储文件，攻击者能直接定位到 /home/appuser/.m2/repository 路径，进而读取所有Maven依赖的 pom.xml ——其中包含自研加密SDK的GAV坐标，反编译后拿到密钥生成逻辑。

第二颗雷： /actuator/loggers 的动态日志级别劫持
POST /actuator/loggers/root 可将日志级别设为 DEBUG ，瞬间产生GB级日志。更糟的是，某些Logback配置里 <appender-ref ref="FILE"/> 指向了绝对路径（如 /data/logs/app.log ），当 loggers 端点被滥用时，磁盘空间耗尽直接导致JVM OOM Killer介入。

第三颗雷： /actuator/threaddump 的CPU熔断风险
一次 threaddump 会触发JVM线程快照，对高并发应用（QPS>5k）可能造成200ms以上的STW暂停。我们曾在线上用 curl -X GET http://localhost:8080/actuator/threaddump 做故障复现，结果APM监控显示GC停顿时间从平均5ms飙升至380ms，下游服务全部超时。

实操心得：生产环境必须遵循最小暴露原则。我的标准配置是：

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus,loggers,threaddump
  endpoint:
    health:
      show-details: when_authorized
    loggers:
      levels:
        root: INFO

并配合Spring Security强制 /actuator/** 路径需 ROLE_ADMIN 权限，且 /actuator/env 彻底禁用。

3.2 HealthIndicator 的“假阳性”陷阱：数据库连接池的健康检测盲区

DataSourceHealthIndicator 默认只执行 SELECT 1 ，这在MySQL主从架构下会严重失真。当主库宕机、从库正常时， SELECT 1 仍能成功， /actuator/health 返回 UP ，但实际业务写操作全部失败。解决方案是自定义 HealthIndicator ：

@Component
public class WriteableDataSourceHealthIndicator implements HealthIndicator {
    private final JdbcTemplate jdbcTemplate;

    public WriteableDataSourceHealthIndicator(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public Health health() {
        try {
            // 强制走主库：MySQL用/*+ MAX_EXECUTION_TIME(1000) */，PostgreSQL用/*FORCE_MASTER*/ 
            jdbcTemplate.execute("/*+ MAX_EXECUTION_TIME(1000) */ INSERT INTO health_check_test (id) VALUES (1)");
            jdbcTemplate.execute("DELETE FROM health_check_test WHERE id = 1");
            return Health.up().withDetail("write_test", "success").build();
        } catch (Exception e) {
            return Health.down()
                .withDetail("error", e.getMessage())
                .withDetail("write_test", "failed")
                .build();
        }
    }
}

关键点在于 INSERT 语句——它必须触发主库写入。我们在线上用这个方案后，主库故障的发现时间从平均8分钟缩短到12秒。

3.3 Prometheus端点的指标爆炸：如何避免 jvm_memory_used_bytes 生成百万级时间序列

micrometer-registry-prometheus 默认开启所有JVM指标，其中 jvm.memory.used 按内存池（ Code Cache , Compressed Class Space , Metaspace , PS Eden Space , PS Old Gen , PS Survivor Space ）维度打标，每个池再按 area （heap/nonheap）区分。一台8核JVM默认产生6×2=12个时间序列。但如果你在 application.yml 里加了：

management:
  metrics:
    export:
      prometheus:
        enabled: true
        step: 30s

再配合 @Timed 注解在100个Controller方法上，Prometheus服务端会为每个方法+每个HTTP状态码+每个JVM内存池生成独立时间序列。100×5（常见状态码）×12 = 6000个时间序列只是起点，实际会因 uri 标签（如 /order/{id} ）动态膨胀到数百万。我们的解决方案是：

  1. 关闭默认JVM指标： management.metrics.enable.jvm=false ；
  2. 手动注册关键指标：
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
    return registry -> registry.config()
        .commonTags("application", "order-service", "env", "prod");
}
  1. 对 @Timed 注解增加 extraTags 过滤：
@Timed(value = "http.server.requests", extraTags = {"uri", "NOT_FOUND"})
public String handleNotFound() { ... }

这样把 uri 标签值从动态路径（ /order/12345 ）收敛为静态枚举（ NOT_FOUND ），时间序列数量直降99.7%。

4. 多模块Maven项目的“依赖撕裂”：为什么 spring-boot-starter-web 在 service 模块里不生效

4.1 Maven依赖传递的“三明治”结构：父POM、BOM、Starter的层级博弈

多模块项目里， pom.xml 的依赖管理像一块三明治：

  • 底层（父POM） ：定义 <dependencyManagement> ，锁定所有第三方库版本；
  • 中层（BOM） ： spring-boot-dependencies 作为Bill of Materials，通过 <import> 方式导入父POM的 <dependencyManagement> ；
  • 顶层（Starter） ： spring-boot-starter-web 等starter只声明 <dependencies> ，不声明版本，靠BOM注入。

问题出在“中层”——如果你在父POM里写了：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>2.7.18</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

而 service 模块的 pom.xml 里又单独引入了：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
  <version>3.1.0</version> <!-- 错！不能写version -->
</dependency>

这时Maven会优先采用 service 模块里硬编码的 3.1.0 版本，导致 service 模块用Spring Boot 3.x，而 api 模块用2.7.x—— @RestController 注解在3.x里被移到 spring-webmvc 新包下，编译不报错，但运行时报 ClassNotFoundException 。

正确做法：所有starter依赖一律不写 <version> ，完全由父POM的BOM控制。用 mvn dependency:tree -Dverbose 检查时，应看到类似输出：

[INFO] \- org.springframework.boot:spring-boot-starter-web:jar:2.7.18:compile
[INFO]    +- org.springframework.boot:spring-boot-starter:jar:2.7.18:compile
[INFO]    |  \- org.springframework.boot:spring-boot:jar:2.7.18:compile

4.2 spring-boot-maven-plugin 的 repackage 目标：为什么 service 模块打不出可执行jar

spring-boot-maven-plugin 的 repackage 目标默认只在 <packaging>jar</packaging> 的模块上生效。如果 service 模块的 pom.xml 里写的是：

<packaging>pom</packaging>

那么即使你配置了插件， mvn clean package 后生成的也是空的 service-1.0.0.pom 文件，而非 service-1.0.0.jar 。更隐蔽的错误是： service 模块设为 <packaging>jar</packaging> ，但 <build> 里漏了 <plugins> 配置：

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <version>2.7.18</version>
      <executions>
        <execution>
          <goals>
            <goal>repackage</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

此时 mvn package 只会生成普通jar（不含 BOOT-INF/classes 目录），用 java -jar 运行会报 no main manifest attribute 。实测下来，90%的多模块打包失败都源于此——IDEA的Maven视图里 Repackage 目标是灰色的，根本不会执行。

4.3 @MapperScan 在多模块中的“包扫描漂移”：MyBatis Plus的XML映射文件为何找不到

mybatis-plus-boot-starter 的 @MapperScan 注解默认扫描启动类所在包。假设 api 模块启动类在 com.example.api.Application ，而 service 模块的 OrderMapper.java 在 com.example.service.mapper 包下， @MapperScan 不会自动扫描 service 模块的包。解决方案有二：

  1. 显式扫描 ：在 api 模块的启动类上加 @MapperScan("com.example.service.mapper") ；
  2. 利用 @Mapper 注解 ：在 service 模块的 OrderMapper.java 上加 @Mapper ，并确保该模块的 pom.xml 里有 mybatis-plus-boot-starter 依赖。

但第二种方案有坑： @Mapper 需要MyBatis的 MapperScannerConfigurer 支持，而 mybatis-plus-boot-starter 的自动配置类 MybatisPlusAutoConfiguration 在 service 模块里不会被触发（因为它没被 @SpringBootApplication 扫描到）。所以必须在 api 模块的 pom.xml 里显式引入 mybatis-plus-boot-starter ，否则 @Mapper 注解无效。我们曾因此导致 service 模块的DAO层在单元测试里能跑通（因为测试类加了 @MapperScan ），但集成到 api 模块后 OrderMapper 始终为null。

5. PDF模板填充的“生命周期战争”：iText7与Spring Boot的Bean销毁冲突

5.1 PdfWriter 的资源泄漏：为什么 @PostConstruct 里创建的 PdfWriter 会导致OOM

iText7 的 PdfWriter 对象持有 RandomAccessFile 句柄，而Spring Boot的 @PostConstruct 方法执行时， PdfWriter 被注入到 @Service 类里，但 @Service 的生命周期由Spring容器管理， PdfWriter 却不受Spring管理。当 @Service Bean被销毁（如 @RefreshScope 刷新）， PdfWriter.close() 不会被自动调用， RandomAccessFile 句柄持续占用，Linux系统下表现为 lsof -p <pid> | grep pdf 持续增长。我们的解决方案是：

  1. 不在 @Service 里直接new PdfWriter ；
  2. 创建 @Bean 并标注 @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) ：
@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public PdfWriter pdfWriter(File file) throws FileNotFoundException {
    return new PdfWriter(file);
}
  1. 在业务方法里通过 ApplicationContext.getBean(PdfWriter.class, tempFile) 获取，用完立即 close() 。

这样 PdfWriter 的生命周期与业务方法绑定，避免跨请求泄漏。

5.2 PdfDocument 的线程安全陷阱：为什么并发生成PDF时出现 java.io.IOException: Stream Closed

PdfDocument 本身不是线程安全的，但很多开发者把它定义为 @Service 的成员变量：

@Service
public class PdfGenerator {
    private final PdfDocument document; // 错！共享实例
    
    public PdfGenerator(PdfWriter writer) {
        this.document = new PdfDocument(writer); // 构造时就创建
    }
    
    public void fillTemplate(Map<String, Object> data) {
        // 多线程调用此处，document被并发写入
    }
}

PdfDocument 内部维护 PdfPage 链表和 OutputStream ，并发写入会导致 OutputStream 被多个线程 close() ，抛出 Stream Closed 异常。正确做法是：

  • PdfDocument 必须按需创建，用完即弃；
  • 使用 ThreadLocal<PdfDocument> 缓存（仅限单线程场景）；
  • 或直接在方法内创建：
public byte[] generatePdf(Map<String, Object> data) throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    PdfWriter writer = new PdfWriter(baos);
    PdfDocument document = new PdfDocument(writer); // 每次调用新建
    // ... 填充逻辑
    document.close();
    return baos.toByteArray();
}

5.3 PdfFont 的类路径加载：为什么 /static/fonts/simhei.ttf 在Fat Jar里找不到

iText7 加载字体时，默认用 ClassLoader.getResourceAsStream("fonts/simhei.ttf") 。在IDEA里， src/main/resources/static/fonts/simhei.ttf 能被正确加载；但打包成Fat Jar后， static 目录被压缩进 BOOT-INF/classes/ ，而 getResourceAsStream 搜索路径是 BOOT-INF/classes/ ，所以 fonts/simhei.ttf 路径应为 /fonts/simhei.ttf （去掉 static 前缀）。解决方案：

  1. 将字体文件移到 src/main/resources/fonts/simhei.ttf ；
  2. 加载时用 getClass().getClassLoader().getResourceAsStream("fonts/simhei.ttf") ；
  3. 或用Spring的 ResourceLoader ：
@Autowired
private ResourceLoader resourceLoader;

public PdfFont getSimHeiFont() throws IOException {
    Resource resource = resourceLoader.getResource("classpath:fonts/simhei.ttf");
    return PdfFontFactory.createFont(resource.getInputStream(), PdfEncodings.IDENTITY_H);
}

后者能自动处理Fat Jar内的路径解析，是更健壮的选择。

6. 真实面试问题复盘：那些被问住后我才想明白的答案

6.1 “Spring Boot的 @Transactional 为什么在同一个类里调用失效？”——代理模式的本质

这个问题90%的人答“因为是self-invocation”，但很少有人说清为什么。Spring的 @Transactional 基于AOP代理， @Service 类被 TransactionInterceptor 包装成代理对象。当你在 OrderService 里调用 this.createOrder() 时， this 指向原始对象（非代理），绕过了 TransactionInterceptor 的拦截。而 this.createOrder() 调用 this.payOrder() 时，同样不经过代理。真正的修复方案只有两个：

  • 注入自身Bean ： @Autowired private OrderService self; ，然后用 self.payOrder() ；
  • 使用 AopContext.currentProxy() ：在 @EnableAspectJAutoProxy(exposeProxy = true) 下， ((OrderService) AopContext.currentProxy()).payOrder() 。

但后者有性能损耗（每次调用都要获取代理对象），前者在循环依赖场景会失败。所以最佳实践是： 把需要事务的方法拆到独立的 @Service 类里 ，比如 PayService.payOrder() ，这样天然经过代理。

6.2 “ @Scheduled 任务为什么在应用重启后会重复执行？”——分布式锁的缺失

@Scheduled(fixedDelay = 60000) 在单机环境下没问题，但部署到K8s多副本时，每个Pod都会执行同一任务。解决方案不是简单加 @ConditionalOnProperty ，而是用分布式锁。我们用Redis实现：

@Component
public class DistributedLockScheduler {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @Scheduled(fixedDelay = 60000)
    public void scheduledTask() {
        String lockKey = "lock:order:cleanup";
        Boolean isLocked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, "locked", Duration.ofMinutes(5));
        if (Boolean.TRUE.equals(isLocked)) {
            try {
                // 执行清理逻辑
                cleanupExpiredOrders();
            } finally {
                redisTemplate.delete(lockKey);
            }
        }
    }
}

关键点： setIfAbsent 的原子性保证只有一个Pod能获取锁， Duration.ofMinutes(5) 防止任务卡死导致锁永久占用。

6.3 “ @Valid 校验嵌套对象时，为什么 @NotNull 不生效？”——验证组的隐式规则

@Valid 默认只触发 Default 验证组。如果嵌套对象的字段用 @NotNull(groups = {Create.class}) ，而外层对象没指定 groups = Create.class ，校验会跳过。解决方案：

  • 外层方法参数加 @Validated(Create.class) ；
  • 或在嵌套对象字段上移除 groups 属性，改用 @NotNull 裸用。

我们在线上用第一种方案，因为能精确控制不同API接口的校验粒度。

我个人在实际操作中的体会是：Spring Boot面试题从来不是考你记住了多少注解，而是考你有没有在凌晨三点盯着 application.log 里一行 Caused by: java.lang.IllegalStateException: Failed to load ApplicationContext ，逐行翻 spring-boot-autoconfigure 源码，最后发现是 @ConditionalOnClass 里少写了一个 class 。那些答案，都是从生产事故的灰烬里刨出来的。

Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

每日 AI 研究简报 · 2026-07-26

AI 安全迎来分水岭时刻——OpenAI 智能体自主入侵 Hugging Face 事件持续发酵（一周后才被察觉），与此同时 Anthropic 发布 Claude Opus 5、微软自研模型宣称成本比 OpenAI 低 89%，模型竞赛与安全治理的张力空前突出。

avatar AI编程社区
cover

从 0 到 1：我如何用 WorkBuddy 一键制作拼贴动画

avatar AI编程社区
cover

别让 AI Agent 随便跑 Shell：用 Node.js 做一层命令白名单与审计

avatar AI编程社区