每年九月到十月的招聘季，是 Java 后端岗位机会最集中、竞争也最激烈的时段。很多候选人把简历写完后就开始批量海投，结果一个月过去，沟通记录不少，真正约面的却没几个。问题往往不是技术不行，而是简历在第一轮就被筛掉了。这篇文章从 HR 和面试官的筛选视角出发，分析 Java 后端简历石沉大海的常见原因，同时给出项目描述、技术栈呈现、场景题和 AI 大模型方向的准备思路，帮你在这一轮求职里减少无效投递。

1. 金九银十，为什么你的 Java 简历无人问津

1.1 海投简历的低效逻辑

很多求职者默认“多投一份简历就多一分机会”，于是同一份简历一键发送给几十个岗位。但从招聘侧看，这种投递方式恰恰是最低效的。

原因有三点：

• HR 收到的简历量在招聘季会成倍增长，能分给每份简历的时间非常有限。
• 岗位 JD 里往往有明确的技术栈和业务要求，比如 Spring Cloud 微服务、高并发场景、消息队列、Redis 缓存等，简历里没有这些关键词，就会被直接过滤。
• 海投简历很难体现你与目标岗位的匹配度，即使你的能力达标，HR 也需要在很短时间里判断“这个人是否值得进入下一轮”。

换句话说，海投只是在增加曝光量，并不等于增加面试机会。想让简历被打开后不被马上关闭，核心是让 HR 在最短时间内找到“你符合岗位要求”的证据。

1.2 HR 一秒钟筛掉简历的四个真相

HR 不是技术专家，但她们每天会看大量简历，已经形成了一套非常固定的扫描习惯。一份简历被快速筛掉，通常离不开下面几种情况。

第一种，简历命名和格式混乱。很多招聘平台会自动转存简历，但如果你通过邮箱或微信投递，文件命名是“新建文档.pdf”，或者发了一个 Word 版导致排版错乱，第一印象就会打折扣。

第二种，缺少岗位 JD 中的核心关键词。比如岗位要求“Spring Boot + MySQL + Redis + MQ”，你的简历技术列表里却是“Java、MySQL、Maven、Git”这类通用技能，HR 很难判断你是否匹配。

第三种，项目描述全是流水账。只写“参与了 XX 系统开发，实现了订单模块，负责接口编写”，没有技术难点，没有数据指标，没有你在项目中的具体贡献，面试官也无法判断你的真实水平。

第四种，工作经历和岗位需求错位。比如岗位希望招聘 3 年以上、有高并发和微服务经验的后端，你的简历大量篇幅在写管理后台增删改查，自然容易被判定为“级别不够”。

1.3 简历通过率取决于什么

筛选一份 Java 后端简历，本质上是在回答三个问题：

• 候选人是否具备岗位所需的技术栈？
• 候选人是否做过贴近业务场景的实战项目？
• 候选人的技术深度是否足够支撑岗位要求？

这三个问题的答案都会体现在简历的技术栈列表、项目描述和亮点提炼里。所以不要把简历当成工作经历的流水账，而要当成一份“技术能力证明文件”来写。

2. 简历基础关：从命名到关键词匹配

2.1 简历命名与投递方式

简历命名建议直接包含三要素：岗位、姓名、工作年限。比如：

Java后端开发-张三-3年经验-联系方式.pdf

这种命名方式一方面方便 HR 归类，另一方面也避免对方保存时还要手动重命名。投递方式上，优先使用 PDF 格式，保证在不同设备上打开都不会乱码。如果通过邮件投递，邮件正文不要只写“附件是我的简历”，可以简单列出你与岗位匹配的 2-3 个点，帮助 HR 快速判断。

简历里的联系方式、工作年限、期望城市、到岗时间也要写在显眼位置，这些信息在 HR 第一轮筛选时非常重要。

2.2 简历里的“搜索词”思维

HR 筛选简历时往往会借助招聘平台的关键词搜索功能。你的简历里技术与岗位 JD 不一致，等于在搜索结果里隐身。所以写技术栈之前，先仔细看目标岗位的要求，把核心词覆盖到简历中。

Java 后端岗位最常见的技术关键词包括：

• Java、Spring Boot、Spring Cloud、MyBatis、MyBatis-Plus
• MySQL、Redis、RabbitMQ、Kafka、RocketMQ
• Docker、Kubernetes、Nginx、Linux
• 微服务、分布式、高并发、消息队列、缓存、分库分表
• Elasticsearch、MongoDB、XXL-Job
• Maven、Git、Jenkins、Apollo 配置中心

需要注意，“覆盖关键词”不代表把简历写成词条堆砌。技术栈列表可以按“熟练掌握、了解、使用过”分层描述，并在项目经验里自然体现这些技术是怎么用的，这样才能通过关键词匹配，又不让面试官觉得你在凑字数。

2.3 工作经历与项目时间线的表达

工作经历建议按倒序排列，每段经历下面用 2-4 个要点说明你负责的系统和主要贡献。不要只写“负责 XX 系统开发”，而要写清楚用了什么技术、解决了什么问题、带来了什么结果。

时间线上要保持一致，避免出现连续多段经历重叠，也不要留下无法解释的空窗期。如果某段经历时间较短，比如只有半年，建议准备一个合理的说明，因为面试官大概率会追问。

3. 项目经验：从流水账改成技术亮点

3.1 项目描述的四大必备要素

项目经验是 Java 后端简历里最值得反复打磨的部分。一个高质量的项目描述通常包含四类信息：

• 业务背景：项目解决的是什么业务问题，面向什么用户，核心流程是什么。
• 你的职责：你在项目中负责哪些模块，是核心开发还是项目主导。
• 技术方案：选型了哪些技术栈，为什么这么选，比如为什么用 Redis 缓存、为什么引入 MQ。
• 量化结果：性能指标、稳定性指标、业务效果，比如接口耗时、支撑的订单量、可用性等。

数字是最有说服力的语言。哪怕是“优化了查询速度”，也比不上“将列表页响应时间从 2s 优化到 300ms”更有冲击力。

3.2 项目描述改造前后对比

以电商订单模块为例，下面是一段很常见的“低分描述”：

参与 XX 电商系统开发，负责订单模块，基于 Spring Boot + MyBatis 实现订单创建和列表查询，修复若干线上 Bug。

这段描述的问题在于：看不出候选人做了什么，看不出技术难度，也看不出业务复杂度。即使你参与了一个很复杂的系统，写成这样也会被认为是简单业务开发。

同样一个模块，改成下面这种写法效果会好很多：

负责订单下单链路从 0 到 1 的设计与开发，基于 Spring Boot + MySQL + Redis + RabbitMQ 实现高并发下单。
通过 Redis 预扣库存 + Lua 脚本保证库存扣减原子性，将下单接口 TP99 从 800ms 优化到 120ms。
引入 MQ 异步处理积分、短信、订单状态通知等非核心逻辑，降低接口响应时间，支撑日均 50 万订单量。

第二版描述增加了技术难点、解决方案和量化结果，面试官一眼就能看出候选人具备高并发、缓存、消息队列相关经验，也更容易围绕这个项目展开提问。

需要注意，简历里的数据要真实、能解释、经得起追问。如果面试官问“TP99 是怎么统计的”，你说“我当时随口写的”，印象分会瞬间归零。

3.3 合适的项目类型怎么选

很多候选人会纠结，自己没有大型互联网项目经验，简历应该写什么。

这里有一个经验性的判断标准：比起项目规模，面试官更看重你是否完整负责过某条链路、是否遇到过真实问题、是否有自己的思考。

适合写进 Java 后端简历的项目包括：

• 电商或交易类系统：商品、订单、库存、支付回调、对账。
• 内容与互动平台：用户体系、发帖评论、点赞关注、消息通知。
• 企业级中后台系统：权限管理、流程审批、报表导出、定时任务。
• 中间件或平台类工具：接口网关、配置中心、任务调度、日志采集。
• AI 应用类系统：知识库问答、智能客服、内容生成、模型调用封装。

如果你确实没有公司级项目，可以做个人项目，但必须用工程化的标准要求自己：代码结构清晰、有单元测试、有 README 文档、有部署地址，最好还能提供设计文档和接口文档。

4. 技术面试准备：从八股文到场景题

4.1 先分清八股文和场景题的区别

Java 后端面试向来对基础能力要求较高，很多人把大量时间用来背八股文，但面试时仍会觉得不够用。核心原因是八股文考察的是“你知道什么”，场景题考察的是“你遇到问题会怎么解决”。

举个例子，同样是并发编程相关的问题：

• 八股文可能会问：synchronized 和 ReentrantLock 的区别是什么？volatile 的底层原理是什么？
• 场景题可能会问：一个秒杀接口，如何防止超卖？如果 Redis 挂了怎么办？如何保证扣库存和订单创建的一致性？

八股文答得好，说明你有理论基础；场景题答得好，才说明你有实战能力。招聘季面试竞争激烈，场景题的表现往往决定了最终评级。

建议准备方式：先理解核心原理，再把原理映射到真实业务场景中，最后整理出自己的“答题模板”。比如聊到线程池，不要只背参数，要清楚线程池在项目里解决过什么问题、核心线程数和队列容量是怎么定的、拒绝策略如何选择。

4.2 Java 并发编程高频考点与代码实战

并发编程是 Java 后端面试的必考模块，高频考点包括：

• Thread 与 Runnable、Callable、Future 的区别
• synchronized 的锁升级过程，重量级锁和轻量级锁
• volatile 的可见性和有序性，以及它不能保证原子性
• JUC 包下的 Lock、Condition、Semaphore、CountDownLatch、CyclicBarrier
• ConcurrentHashMap 的底层实现和 JDK 1.7/1.8 区别
• ThreadPoolExecutor 的七个参数，以及 Executors 创建线程池的弊端
• AQS 的基本原理
• ThreadLocal 的内存泄漏问题
• CompletableFuture 异步编排与性能优化

线程池是并发编程的高频面试点，下面是一个手动创建线程池的示例，建议熟记并理解每个参数：

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ThreadPoolDemo {

    public static void main(String[] args) {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                4,                       // 核心线程数
                8,                       // 最大线程数
                60L,                     // 空闲线程存活时间
                TimeUnit.SECONDS,        // 存活时间单位
                new ArrayBlockingQueue<>(1000),  // 任务队列
                new ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略
        );

        for (int i = 0; i < 100; i++) {
            int taskId = i;
            executor.execute(() -> {
                System.out.println(Thread.currentThread().getName() + " 执行任务：" + taskId);
            });
        }

        executor.shutdown();
    }
}

示例理解：核心线程数为 4，任务量超过 4 时，新任务会进入队列等待；队列容量是 1000，当队列也满了，才会创建新的线程直到最大线程数 8；如果线程数已经到 8、队列也已经满，新任务就会触发拒绝策略。CallerRunsPolicy 的意思是让提交任务的线程自己执行该任务，适合对任务丢失敏感、但可以接受速度下降的场景。

很多面试题会问“Executors 为什么有问题”，因为 FixedThreadPool 和 SingleThreadPool 的队列容量是 Integer.MAX_VALUE，任务堆积过多时容易引发内存溢出；CachedThreadPool 的线程数上限也是 Integer.MAX_VALUE，极端情况下会创建大量线程。因此生产环境更推荐手动调整参数。

再看一个 CompletableFuture 异步编排的例子，这是现代 Java 后端面试里很喜欢问的题目，特别是在多接口聚合、聚合查询优化场景中：

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class CompletableFutureDemo {

    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(5);

        CompletableFuture<String> userFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟调用用户服务
            return "用户信息";
        }, pool);

        CompletableFuture<String> orderFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟调用订单服务
            return "订单信息";
        }, pool);

        CompletableFuture<String> couponFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟调用优惠券服务
            return "优惠券信息";
        }, pool);

        // 三个任务并行执行，全部完成后合并结果
        CompletableFuture<String> result = userFuture
                .thenCombine(orderFuture, (u, o) -> u + " + " + o)
                .thenCombine(couponFuture, (prev, c) -> prev + " + " + c);

        System.out.println(result.get());

        pool.shutdown();
    }
}

这种写法可以用在一个页面需要同时展示用户信息、订单信息和优惠券信息的场景，把串行调用改成并行调用，接口耗时可以大幅下降。

4.3 场景题如何答：以秒杀系统为例

秒杀类场景是后端面试中出现频率极高的题目，因为它能把缓存、并发、事务、消息队列、接口幂等串在一起考察。

一个简洁但完整的秒杀设计思路可以拆成下面几个环节。

整体流程分成两层：

1. 前置拦截：用户进入秒杀页面时，先查询 Redis 中的商品库存，如果已售罄直接返回“已抢完”，避免大量请求打到数据库。
2. 扣减库存：在 Redis 中通过 Lua 脚本原子性地校验并扣减库存，扣减成功后再发送 MQ 消息，由订单服务异步生成订单。

数据库层加唯一约束：

• 用户 ID + 活动 ID 建立唯一索引，防止同一个用户重复下单。

对库存扣减，Redis Lua 脚本是最常用的一种方案，示意如下：

-- KEYS[1] 是库存 key，ARGV[1] 是本次扣减数量
local stock = tonumber(redis.call('GET', KEYS[1]) or '0')
if stock < tonumber(ARGV[1]) then
    return 0
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1

面试官如果继续往下问，通常会问这些延伸点：

• 扣库存成功了，但 MQ 消息发送失败怎么办？可以引入本地消息表，先写本地事务，再通过定时任务或 MQ 确认机制保证最终一致性。
• 订单服务 MQ 消费失败怎么办？需要有消费重试机制，并且在消费逻辑里做好幂等。
• 商品超卖如何兜底？数据库的库存字段做扣减更新时使用条件判断，比如 UPDATE t_sku SET stock = stock - 1 WHERE id = ? AND stock > 0 ，并检查影响行数。

这类题目没有固定标准答案，关键在于你能不能在连环追问下保持逻辑闭环。

4.4 后端框架与数据库考察重点

除了并发编程，Java 后端面试通常还会覆盖以下技术栈：

Spring 与 Spring Boot：

• Bean 生命周期，BeanFactory 和 ApplicationContext 的关系。
• Spring 循环依赖的解决机制，三级缓存的作用。
• @Transactional 失效的常见场景。
• Spring AOP 的实现原理，静态代理和动态代理的区别。

MySQL：

• 索引数据结构，为什么用 B+ 树。
• 最左前缀原则，索引失效的常见情况。
• 事务隔离级别，MVCC 实现原理。
• 慢 SQL 排查思路，Explain 执行计划怎么看。

Redis：

• Redis 常用数据结构以及适用场景。
• 缓存穿透、缓存击穿、缓存雪崩的区别和解决方案。
• Redis 分布式锁的正确用法，为什么推荐 Redisson。
• 缓存与数据库一致性如何保证。

消息队列：

• 为什么使用 MQ，它解决什么问题。
• 如何保证消息不丢失、不重复消费。
• 消息积压如何处理。

这部分内容建议不要只背结论，每个知识点都找一个你项目中使用过的例子，把技术落到场景里，面试时会从容很多。

5. AI 与大模型：Java 后端求职的加分项

5.1 为什么后端面试开始聊 AI

今年招聘市场上，AI 相关的岗位热度很高，但并不是只有算法岗需要懂 AI。越来越多的企业在招聘 Java 后端时，会额外关注候选人是否了解大模型接口调用、Prompt 工程、RAG 知识库、AI Agent 的编排方式。

原因是，企业并不缺一个能写 CRUD 的后端开发，但非常缺“能把大模型能力接入现有业务系统”的人。比如做一个智能客服，后端需要负责会话上下文管理、调用模型接口、处理流式返回、把搜索结果组装成回答内容，再对接已有的用户体系。这套链路本质上仍然是后端工程问题，只是业务逻辑从传统规则变成了大模型能力。

所以，Java 后端候选人如果能提前掌握一部分 AI 应用集成能力，在简历筛选和面试中都会是明显的加分项。

5.2 Java 程序员可以掌握哪些 AI 集成能力

不需要你去训练模型，后端开发真正需要掌握的 AI 相关内容主要有这几种：

• 调用大模型 API 并处理请求和响应，包括普通 JSON 请求和流式响应。
• 设计对话上下文管理，控制 requests 的 messages 列表，避免上下文过大。
• 掌握 Prompt 的基本构造方法，比如系统角色设定、用户输入、few-shot 示例。
• 了解 RAG（检索增强生成）的基本流程：文档解析、切片、向量化、向量检索、拼接 Prompt。
• 了解 Agent 的简单概念，比如工具调用、多轮规划、回调函数。

这些能力不需要你从头学算法，只要会 HTTP 调用、JSON 解析、数据库查询，就能做出一个可演示的 AI 应用。

5.3 示例：Spring Boot 封装一个大模型接口调用

下面是一个 Java 后端接入大模型的极简示例，假设你们团队已经配置好了一个模型服务网关，接口协议兼容常见的 chat/completions 格式。

// 文件路径：src/main/java/com/example/ai/AiChatService.java
package com.example.ai;

import org.springframework.http.*;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

@Service
public class AiChatService {

    private final RestTemplate restTemplate;

    public AiChatService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String chat(String prompt) {
        String url = "http://gateway.example.com/v1/chat/completions";

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        headers.setBearerAuth(System.getenv("LLM_API_KEY"));

        Map<String, Object> body = new HashMap<>();
        body.put("model", "your-model-name");
        body.put("messages", List.of(
                Map.of("role", "system", "content", "你是一个专业的 Java 技术助手"),
                Map.of("role", "user", "content", prompt)
        ));

        HttpEntity<Map<String, Object>> request = new HttpEntity<>(body, headers);
        ResponseEntity<Map> response = restTemplate.postForEntity(url, request, Map.class);

        if (response.getBody() != null) {
            List<Map> choices = (List<Map>) response.getBody().get("choices");
            if (choices != null && !choices.isEmpty()) {
                Map message = (Map) choices.get(0).get("message");
                return (String) message.get("content");
            }
        }
        return "";
    }
}

这段代码是核心逻辑示意，生产环境中建议：

• 使用 DTO 接收响应，避免 Map 泛型带来的类型安全问题。
• 将模型名称、网关地址放到配置中心，不要硬编码。
• 如果模型供应商提供了官方 Java SDK，优先使用官方 SDK。
• 对接口调用增加超时、重试、熔断和日志记录。

如果你的项目里真正实践过类似接口，并解决了 Token 数量限制、响应超时、流式返回解析等问题，这段经历非常值得写进简历。但如果没有真实项目，不要只靠概念堆砌，面试官一旦追问细节就会露馅。

5.4 简历里如何呈现 AI 项目

简历中如果有 AI 相关项目，建议写清楚业务形态和技术链路。

一个比较好的项目描述示例：

搭建企业智能客服系统，负责后端服务整体设计。
基于 Spring Boot + Redis + MySQL 实现用户会话管理，调用大模型接口完成问答生成。
为了解决知识库回答不准确的问题，引入 RAG 方案：将企业文档解析后向量化，存入向量数据库，
用户提问时先进行向量检索，再把检索结果拼接为 Prompt 后调用模型接口，回答准确率提升约 30%。

这里的关键点在于，你没有写“我精通大模型”，而是用一条清晰的技术链路证明了你能把 AI 能力落地到业务中。数据同样需要真实、可解释。

5.5 不要盲目堆砌 AI 关键词

需要特别提醒的是，“AI 大模型”是热门方向，但不是所有 Java 岗位都要求具备这个能力。如果你的简历里没有任何 AI 项目，没必要硬写一堆“熟悉大模型、了解 RAG、了解 Agent”之类的标签。原因很简单：面试官只要追问“你用过哪个框架”“你调过什么接口”“向量库用的什么”，就会发现你只是看过相关文章。

更好的策略是：选择一条主线，比如智能客服、知识库问答、内容助手，花一两周时间做一个简单 demo，真正做到调通接口、处理数据、部署上线，再把它写进简历。这时候你的回答才有支撑。

6. 常见问题与避坑清单

6.1 简历常见扣分项

问题现象	常见原因	改进思路
简历命名混乱	使用“新建文档.pdf”或 Word 格式	统一命名为“岗位-姓名-年限.pdf”
技术列表太泛	只写 Java、MySQL 等通用技能	对照 JD 补充 Spring Cloud、Redis、MQ 等关键词
项目描述流水账	只写负责模块，不写难点和结果	用“业务背景 + 我的职责 + 技术方案 + 量化结果”重写
工作经历断层	短暂经历或空窗期未解释	提前准备说明，突出期间的成长或项目产出
缺少个人亮点	全是业务开发，看不出技术深度	选择一到两个技术难点展开写，比如性能优化、分布式事务

6.2 面试高频翻车点

面试翻车并不一定是因为你不会，很多时候是准备方向和表达方式出了问题。

高频翻车点包括：

• 项目讲不清：面试官让你介绍项目，你从业务背景讲到数据库表结构，却没有提炼出技术难点和解决方案。
• 八股文和项目脱节：你能背出 Redis 持久化机制，但项目里为什么用 Redis、如何保证缓存一致性，完全答不上来。
• 场景题没有思路：遇到“怎么做幂等”“怎么做分布式锁”“消息丢了怎么办”这类问题时，答不出排查节奏和兜底方案。
• 遇到内存溢出报错没有排查思路：像 java.lang.OutOfMemoryError 这类问题，面试官不期待你背 JVM 参数，而是期待你能说出一套排查流程，比如先看堆内存还是元空间、用 jstat 还是 jmap、如何分析 dump 文件。
• 环境问题消耗过多时间：比如 Lombok 在编译器下不生效、依赖冲突、JDK 版本不对，这类问题如果平时不熟悉，很容易在面试练手环节卡住。

建议在面试前整理一份“项目自问自答”文档，把可能被追问的问题提前写好答案，包括：项目核心表结构、核心接口链路、出过什么线上问题、如何排查、如果重做会怎么设计。

6.3 投递策略与时间节奏

招聘季时间有限，不建议无差别海投。更合理的投递策略是：

• 每天花时间筛选岗位，优先投递技术栈匹配度高、业务方向符合自己规划的岗位。
• 同一天内不要集中投递太多岗位，避免多个面试时间撞车。
• 每投递一个岗位，根据 JD 微调一次简历中的技术栈和项目顺序。
• 投递后不要干等，可以主动补充一段简短的自荐语，用两三句话说明自己的核心匹配点。
• 定期复盘投递数据，如果连续两周没有面试邀约，优先检查简历，而不是继续增加投递量。

7. 行动清单与长期规划

把这一轮求职的核心动作梳理成清单，你可以按顺序执行。

1. 简历重构：选 2-3 个重点岗位 JD，对照 JD 重写两段核心项目描述，补上技术关键词、数字指标和个人职责。
2. 项目深挖：针对简历中的主项目，准备一份技术问答文档，覆盖项目架构、核心难点、线上问题、性能优化、设计取舍。
3. 并发编程重点突破：把线程池、锁、并发容器、CompletableFuture、AQS 原理过一遍，并用代码实际操作验证。
4. 场景题专项：每天练习一个场景，比如秒杀、订单超时、缓存穿透、接口幂等、消息积压，养成“先讲整体方案，再讲细节”的答题习惯。
5. AI 能力补强：如果时间允许，做一个与大模型接口集成的 demo，亲手跑通一次完整链路，再考虑写进简历。
6. 投递节奏控制：不要一次性海投，按照技术栈匹配度分批次投递，每次投递前微调简历。
7. 复盘与调整：两个星期内如果没有约面，重新检查简历关键词、项目描述和岗位匹配度，不要盲目认为“市场行情不好”。

金九银十的机会窗口很集中，但机会更偏向准备充分的人。与其继续一键海投，不如先把简历、项目、场景题和 AI 应用能力这四件事真正打磨到位，再开始精准投递。如果这篇文章对你有帮助，可以收藏备用，也欢迎在评论区聊聊你遇到的简历筛选问题。