Java 已死？这恐怕是近年来技术圈最具争议性的话题之一。但真相是，Java 不仅没死，其生态反而在云原生、微服务、大数据等关键领域持续深化。真正让许多开发者感到“寒气”的，并非语言本身，而是在当前竞争激烈的求职市场中，简历上普遍缺少一个能直接证明你具备“解决复杂问题”和“支撑高并发业务”能力的关键项。这个关键项，就是 系统性的高并发、高可用架构设计与实战经验 。

简单来说，企业招聘中高级 Java 工程师或架构师时，早已不满足于你会用 Spring Boot 写 CRUD、会背八股文。他们需要看到你简历上有能拿得出手的、有数据支撑的 性能优化案例 、 线上故障排查与解决记录 ，以及 从零到一或深度参与过的、有挑战性的系统架构演进过程 。缺少这项，你的简历在海量“熟练使用 Spring Cloud、MySQL、Redis”的候选人中，很难脱颖而出。

本文不讨论空洞的概念，而是直接切入核心：如何为你的 Java 后端简历补上这最关键的一块拼图。我们将围绕 MySQL 和 Redis 这两个几乎必考的核心组件，拆解出从“会用”到“精通”再到“能设计、能优化、能抗住压力”的实战路径。无论你是准备跳槽涨薪，还是瞄准架构师岗位，这篇文章将提供一套可立即行动、能写入简历的“硬核经验”构建指南。

1. 核心能力速览：Java 后端工程师的简历价值分层

在深入细节前，我们先通过一个表格，快速看清当前市场对 Java 后端能力的需求分层，以及你简历上对应的“含金量”项目。

能力层级 典型描述（简历常见话术） 问题与瓶颈 高价值简历项（关键项）
基础应用层 熟练使用 Spring Boot/Cloud, MyBatis, 了解 MySQL/Redis 基本操作。 同质化严重，无法体现深度。仅证明“用过”，无法证明“用好”和“解决过问题”。 无。属于必备基础，不构成优势。
原理理解层 熟悉 JVM 原理、MySQL 索引、Redis 数据结构、多线程与锁。 停留在“知道”层面，面试能答八股，但缺乏实际场景印证，易被追问至细节而露怯。 初步具备：能结合简单业务场景（如一次慢查询优化）说明原理应用。
实战优化层 有线上系统性能调优经验 ，解决过 OOM、慢查询、缓存穿透/雪崩等问题。 开始产生区分度。但描述往往模糊，如“优化了系统性能”，缺乏量化数据和具体技术动作。 核心关键项 ：需包含 具体场景、问题根因、技术方案、量化结果 （如 QPS 提升 X%，RT 降低 Y%）。
架构设计层 负责或主导了某个微服务模块/系统的架构设计，有高可用、高并发设计经验。 高级岗位敲门砖。难点在于如何证明设计是你做的，以及设计是否经受了真实流量考验。 顶级关键项 ：需阐述 业务背景、架构选型对比、容灾方案、数据一致性方案、可观测性建设 ，并有上线后稳定性数据佐证。
工程与协作层 熟悉 DevOps、CI/CD，有代码规范、技术选型、团队培训经验。 架构师必备软技能。需要具体事例支撑，如“引入 XX 工具链，将发布效率提升 XX%”。 加分项：能体现技术领导力和工程化思维的具体项目。

你的目标，是让简历从“原理理解层”扎实地迈向“实战优化层”，并努力触碰“架构设计层”。而 MySQL 和 Redis ，正是实现这一跨越最经典、最普适的战场。

2. 适用场景与能力边界

补强简历关键项，并非鼓励你去编造经历，而是教你如何从日常工作中挖掘、提炼和深化有价值的实战经验，并将其专业地呈现出来。

  • 适合谁 ：
    • 工作 1-3 年，想冲击中高级工程师岗位的 Java 开发者。
    • 工作 3-5 年，技术遇到瓶颈，寻求涨薪或晋升架构师的资深开发。
    • 技能栈停留在框架使用，缺乏系统性性能优化和架构实战经验的开发者。
  • 能解决什么问题 ：
    • 简历筛选关 ：让你的简历在 HR 和初筛官眼中具备“硬核”亮点，通过率大幅提升。
    • 技术面试关 ：当面试官问到“你遇到的最有挑战的技术问题是什么？”时，你有完整、清晰、有深度的案例可讲，主导面试节奏。
    • 薪资谈判关 ：具象化的优化成果和架构贡献，是你要求更高职级和薪资的最有力筹码。
  • 不适合什么场景 ：
    • 应届生或转行初学者（应先夯实基础层）。
    • 期望不付出额外学习和实践，仅靠“包装”话术就能通关（技术面试会深挖细节，无法蒙混）。
  • 能力边界与合规提醒 ：
    • 所有简历经验必须基于真实工作或个人深度实践项目。虚构经历在背景调查和技术深度追问下极易暴露。
    • 涉及公司内部系统数据时，在简历和面试描述中应进行 脱敏处理 ，使用“某电商系统”、“某金融交易模块”、“日订单量百万级”等模糊化表述，重点突出技术动作和通用解决方案。
    • 优化方案应遵循最佳实践，避免为了“炫技”而引入不必要的复杂度。

3. 环境准备：构建你的本地“练兵场”

实战经验离不开实验环境。在你将优化手段应用到线上之前，一个本地的、可复现的压测和调优环境至关重要。

  1. 基础软件栈 ：

    • JDK ：建议 OpenJDK 11 或 17，这是当前企业主流选择。确保安装并配置好 JAVA_HOME 。
    • IDE ：IntelliJ IDEA（终极版功能更全）或 VS Code。
    • 构建工具 ：Maven 或 Gradle。
    • 版本控制 ：Git。

  2. 数据库与缓存 ：

    • MySQL ：推荐使用 Docker 快速部署最新版本（如 8.0）进行学习。生产经验则需针对特定版本（如 5.7）深入。 
      # 拉取并运行 MySQL 8.0
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -p 3306:3306 -d mysql:8.0
    • Redis ：同样使用 Docker 部署。 
      # 拉取并运行 Redis 最新版
docker run --name some-redis -p 6379:6379 -d redis
    • 客户端工具 ：安装 MySQL Workbench 或 DBeaver，Another Redis Desktop Manager 或 RedisInsight，用于直观操作和监控。

  3. 压测工具 ：

    • JMeter ：图形化界面，适合模拟复杂业务场景和生成报告。
    • wrk/wrk2 ：命令行工具，轻量级，适合做 HTTP 基准测试和延迟分析。
    • Apache Benchmark (ab) ：简单快速的 HTTP 压力测试工具。

  4. 监控与诊断工具 ：

    • Arthas ：阿里开源的 Java 诊断神器，动态跟踪线上问题，学习调优必备。
    • JVisualVM / JConsole ：JDK 自带，用于监控 JVM 内存、线程、GC 情况。
    • Slow Query Log ：MySQL 慢查询日志，性能分析起点。
    • EXPLAIN ：MySQL 执行计划分析命令。
    • Redis MONITOR / SLOWLOG ：Redis 监控和慢查询日志。

准备好这些，你就拥有了一个完整的“实验室”，可以安全地复现、分析和解决各种性能问题。

4. 实战路径一：MySQL 深度优化与简历案例打造

MySQL 的优化是一个系统工程，简历上不应只写“熟悉索引”，而应展现你解决具体问题的能力。

4.1 从一次慢查询事故到简历亮点

场景构建 ：假设你负责一个用户订单查询接口，随着数据量增长，接口响应时间（RT）从 50ms 恶化到 2s 以上。

1. 问题定位与根因分析（体现排查能力） ：

  • 动作 ：开启 MySQL 慢查询日志 ( slow_query_log=ON , long_query_time=1 )。
  • 发现 ：捕获到一条典型慢 SQL： 
    SELECT * FROM orders WHERE user_id = ? AND status IN (1,2,3) ORDER BY create_time DESC LIMIT 20;
  • 分析 ：使用 EXPLAIN 分析。 
    EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status IN (1,2,3) ORDER BY create_time DESC LIMIT 20;
    • 可能发现 type 为 ALL （全表扫描）， key 为 NULL （未走索引）。
    • 或者走了 user_id 的单列索引，但 status 和 create_time 排序导致大量回表操作和 filesort 。

2. 解决方案设计与实施（体现技术深度） ：

  • 方案对比 ：
    • 方案A（初级） ：在 user_id 上加索引。效果有限，因为 status 过滤和 create_time 排序问题未解。
    • 方案B（中级） ：建立联合索引 (user_id, status, create_time) 。这是一个覆盖索引的尝试，但 IN 查询可能影响索引最左前缀原则的效率。
    • 方案C（高级） ：根据业务实际数据分布分析。如果 status=1 （进行中）的订单占比极少，而查询 status IN (1,2,3) 是为了查“非完成状态”订单，可以考虑：
      1. 建立联合索引 (user_id, create_time) 并包含 status （作为覆盖索引）。
      2. 在应用层拆分查询，先查 (user_id, status=1) ，若无结果再查 status=2 ，利用索引的有序性避免 IN 和 filesort 。（ 这需要深入理解业务 ）
  • 实施 ：选择方案B或C，在测试环境验证执行计划 ( EXPLAIN ) 和效果。

3. 效果验证与量化（体现结果导向） ：

  • 动作 ：在预发布环境或低峰期，使用相同的 SQL 进行压测对比。
  • 数据 ：
    • 优化前：平均 RT 2000ms，高峰期数据库 CPU 使用率 80%。
    • 优化后：平均 RT 降至 50ms，数据库 CPU 使用率降至 20%。
    • 量化结果 ： 该接口 99 分位 RT 下降 95%，对应数据库服务器 CPU 负载下降 60% 。
  • 衍生优化 ：借此机会，推动建立数据库索引设计规范和 SQL 上线 Review 流程。

简历表述示例 ：

“主导了核心订单查询接口的性能优化。通过分析慢查询日志和 EXPLAIN 执行计划，定位到因索引缺失及 IN 查询使用不当导致的全表扫描与排序瓶颈。设计了基于 (user_id, create_time) 的覆盖索引并结合业务逻辑优化查询方式，使该接口 P99 响应时间从 2s 降至 50ms，数据库服务器 CPU 峰值负载下降 60%，并沉淀了 SQL 审核规范。”

4.2 应对海量数据：分库分表实战经验

当单表数据量达到千万级，索引优化可能触及天花板。分库分表是经典的高阶技能。

场景 ：用户行为日志表，日均增长百万，单表已超 5000 万行，查询和分析缓慢。

1. 选型与设计 ：

  • 拆分策略 ：基于 user_id 进行哈希分片（例如 1024 个分片），确保用户数据分布均匀且查询可路由。
  • 中间件选型 ：对比 ShardingSphere-JDBC（客户端模式，轻量）和 MyCat（代理模式，功能多）。选择 ShardingSphere-JDBC，因其对应用侵入性相对较小，且与 Spring Boot 集成性好。
  • 路由键 ：明确所有相关查询都必须包含 user_id ，否则需要设计广播表或绑定表。

2. 实施难点与解决方案 ：

  • 分布式ID ：放弃数据库自增 ID，采用 Snowflake 算法生成全局唯一 ID。
  • 跨分片查询 ：对于运营后台需要全量数据的查询，引入 Elasticsearch 作为查询补充，通过 binlog 同步数据到 ES。
  • 数据迁移 ：设计双写迁移方案，在低峰期进行历史数据迁移，并实现灰度切换和回滚预案。

3. 简历表述要点 ：

  • 突出复杂度 ：“负责亿级用户行为日志系统的分库分表架构改造。”
  • 体现技术选型 ：“基于 ShardingSphere-JDBC 实现了按 user_id 哈希分片（1024 张分表）的方案。”
  • 说明解决的核心问题 ：“解决了单表数据膨胀导致的慢查询与存储瓶颈，使日志写入和用户维度查询性能保持毫秒级响应。”
  • 提及衍生能力 ：“设计了基于 Snowflake 的分布式 ID 生成方案，并通过 Canal 同步数据至 Elasticsearch 以支持复杂的后台聚合查询。”

5. 实战路径二：Redis 高阶应用与架构设计

Redis 绝不仅仅是 get/set 。简历上应体现你用 Redis 解决了哪些复杂场景下的核心问题。

5.1 穿透、击穿、雪崩：缓存问题的系统性解决

这是经典面试题，但简历上需要的是你 真正解决过 的证据。

场景 ：首页商品信息缓存，遭遇突发大流量。

1. 缓存穿透（查不存在的数据） ：

  • 问题 ：恶意请求查询不存在的商品 ID，绕过缓存直击数据库。
  • 解决方案 ：
    • 布隆过滤器 (Bloom Filter) ：在查询缓存前，先用布隆过滤器判断 key 是否存在。这是 高阶方案 。
    • 缓存空值 ：对查询结果为 null 的 key，也设置一个短时间的缓存（如 30 秒）。这是 通用方案 。
  • 简历表述 ：“针对恶意查询导致的缓存穿透问题，在缓存层前置布隆过滤器，拦截大量非法请求，将数据库 QPS 在攻击场景下降低 99%。”

2. 缓存击穿（热点 key 过期） ：

  • 问题 ：某个热点商品缓存同时失效，大量请求瞬间涌向数据库。
  • 解决方案 ：
    • 互斥锁 (Mutex) ：缓存未命中时，使用 Redis 的 SETNX 命令实现分布式锁，只允许一个线程去重建缓存，其他线程等待。
    • 逻辑过期 ：不给缓存设置物理 TTL，而是将过期时间存在 value 中。异步线程定期扫描并更新。此方案更复杂，但用户体验无抖动。
  • 简历表述 ：“对于‘秒杀商品’这类热点 key，采用 Redis 分布式锁结合双检锁（DCL）机制防止缓存击穿，确保高并发下数据库平稳运行。”

3. 缓存雪崩（大量 key 同时过期） ：

  • 问题 ：大量缓存 key 在同一时间点过期，导致请求批量打到数据库。
  • 解决方案 ：
    • 随机过期时间 ：在基础过期时间上，增加一个随机值（如 30 分钟 ± 5 分钟）。
    • 高可用架构 ：采用 Redis 哨兵（Sentinel）或集群（Cluster）模式，避免单点故障。
    • 服务降级与熔断 ：引入 Hystrix 或 Sentinel（阿里）组件，当数据库压力过大时，快速失败或返回降级内容。
  • 简历表述 ：“通过为缓存 key 设置基础过期时间加随机偏移量，避免了缓存雪崩风险。同时，将 Redis 升级为哨兵集群，并集成熔断降级组件，保障系统整体可用性。”

5.2 从缓存到高速存储：Redis 数据结构的高级玩法

场景 ：实现一个大型社交媒体的实时点赞计数和排行榜。

1. 精准计数与去重 ：

  • 问题 ：用户对同一内容只能点赞一次，且要实时显示点赞数。
  • 解决方案 ：使用 SET 存储点赞用户 ID 实现去重，使用 HINCRBY 或直接操作 SET 的 SCARD 来获取计数。 
    # 用户 user:1001 点赞了帖子 post:500
SADD post:500:liked_by user:1001
# 获取帖子点赞数
SCARD post:500:liked_by
# 判断用户是否点过赞
SISMEMBER post:500:liked_by user:1001

2. 实时排行榜 ：

  • 问题 ：需要根据点赞数、发布时间等维度对内容进行实时排序。
  • 解决方案 ：使用 ZSET （有序集合）。 
    # 帖子收到点赞，分数+1
ZINCRBY post:ranking 1 post:500
# 获取点赞 Top 10 的帖子
ZREVRANGE post:ranking 0 9 WITHSCORES
  • 进阶考虑 ： ZSET 的分数（score）可以设计为复合值，例如 score = 点赞数 * 10000000000 + (发布时间戳) ，以实现“按点赞数排序，点赞数相同按时间排序”的复杂需求。

简历表述示例 ：

“设计并实现了社交模块的实时互动系统。利用 Redis SET 保证点赞行为的幂等性，使用 SCARD 实现毫秒级计数统计。基于 ZSET 构建了多维度的实时内容排行榜（如热榜、新榜），通过精心设计 score 计算规则，支持复杂的排序逻辑，成功支撑了千万级日活下的实时互动需求。”

6. 架构思维体现：从组件优化到系统设计

当你解决了多个具体的 MySQL/Redis 问题后，需要将其串联，展现你的系统架构能力。

案例：设计一个高并发秒杀系统

这是一个经典的架构面试题，也是整合你所有知识的绝佳简历项目（可以是个人学习项目，但设计必须完整）。

1. 架构分层与核心挑战 ：

  • 挑战 ：瞬时超高并发、库存超卖、系统防刷、流量洪峰。
  • 你的设计方案 ：
    • 流量削峰 ：引入消息队列（如 RocketMQ/Kafka），将同步下单请求异步化，前端配合“排队中”动画。
    • 库存扣减 ：这是核心。 绝对不能直接 UPDATE stock SET stock = stock - 1 WHERE id = ? AND stock > 0 在高并发下会有精度问题。
      • 方案一（推荐） ：将库存预热到 Redis。使用 Redis 的 DECR 或 Lua 脚本保证原子性扣减。扣减成功后，再发送异步消息到队列，由消费者进行数据库库存的最终扣减（用于对账和持久化）。
      • 方案二 ：使用数据库的悲观锁（ SELECT ... FOR UPDATE ）或乐观锁（版本号），性能较差，作为备选。
    • 防刷与限流 ：
      • 网关层或 Nginx 限流。
      • 对用户 ID 或 IP 进行频率限制（使用 Redis 的 INCR 和 EXPIRE ）。
      • 验证码、答题等互动挑战。
    • 缓存与降级 ：
      • 商品详情等静态信息全部缓存。
      • 如果 Redis 或数据库压力过大，触发熔断降级，返回“活动太火爆”等友好提示。

2. 简历上如何描述这个“项目” ：

“独立设计并模拟实现了一个高并发秒杀系统架构。核心采用 Redis Lua 脚本 保证库存扣减的原子性与高性能，通过 RocketMQ 进行流量削峰与异步下单，数据库层仅作为最终一致性存储。在网关层集成 Sentinel 实现限流与熔断，并利用 Redis 实现用户级防刷。该架构设计理论上可支撑 10万+ QPS 的秒杀场景，并解决了超卖、雪崩等核心问题。”

关键点 ：使用“设计”、“采用...保证...”、“通过...进行...”、“集成...实现...”等动词突出你的架构决策和整合能力。

7. 资源占用与性能观察：让你的经验可信

在描述优化成果时，提供可观察、可度量的数据。

  • MySQL ：

    • 监控指标 ： QPS 、 TPS 、 连接数 、 慢查询数 、 InnoDB 缓冲池命中率 、 CPU 使用率 、 IOPS 。
    • 工具 ： SHOW GLOBAL STATUS 、 SHOW ENGINE INNODB STATUS 、 pt-query-digest （Percona Toolkit）、云平台 RDS 监控。
    • 简历表述 ：“优化后，该数据库实例的 QPS 从 5000 提升至 12000， InnoDB 缓冲池命中率 从 85% 提升至 99.5%。”

  • Redis ：

    • 监控指标 ： 每秒操作数 (ops/sec) 、 内存使用量 、 连接数 、 键空间命中率 、 网络输入/输出流量 、 CPU 使用率 。
    • 工具 ： INFO 命令、 redis-cli --stat 、 RedisSlowLog 、 RedisMonitor 、可视化客户端。
    • 简历表述 ：“引入缓存后，核心接口 平均响应时间 从 150ms 降至 15ms，Redis 集群的 键空间命中率 长期保持在 98% 以上。”

  • JVM/应用层 ：

    • 监控指标 ： GC 频率与耗时 （Young GC/Full GC）、 堆内存使用情况 、 线程数 、 接口 P99/P95 响应时间 。
    • 工具 ： Arthas （ dashboard 、 thread 、 jad ）、 JVisualVM 、 Prometheus + Grafana （应用埋点）。
    • 简历表述 ：“通过调整 JVM 堆大小及 GC 参数，将 Full GC 频率从每小时数次降低至每天一次以下，服务 P99 延迟 毛刺显著减少。”

8. 常见问题与排查方法清单

将你解决问题的能力结构化，这也是面试官考察的重点。

问题现象 可能原因 排查思路 解决方案
接口响应慢，数据库 CPU 高 1. 慢查询。
2. 未命中索引。
3. 锁等待（行锁、表锁）。		 1. 检查 MySQL 慢查询日志。
2. 对可疑 SQL 执行 EXPLAIN 。
3. 执行 SHOW PROCESSLIST; 查看当前连接和状态。		 1. 优化 SQL，添加或调整索引。
2. 拆分大事务，避免长事务持有锁。
缓存命中率低 1. 缓存 key 设计不合理，粒度太细或太粗。
2. 内存不足，频繁淘汰。
3. 大量访问不存在的数据（穿透）。		 1. 分析 Redis INFO 命令输出的 keyspace_hits 和 keyspace_misses 。
2. 使用 redis-cli --bigkeys 分析大 key。
3. 检查业务逻辑和 key 生成规则。		 1. 重构缓存 key 设计，提高复用性。
2. 增加内存或优化数据结构（如用 hash 代替多个 string ）。
3. 对空值进行缓存或使用布隆过滤器。
Redis 内存持续增长 1. 未设置过期时间。
2. 存在大 key（大 hash，大 list）。
3. 客户端连接泄漏。		 1. 使用 INFO memory 查看内存详情。
2. 用 redis-rdb-tools 分析 RDB 文件。
3. 检查 client list 是否有异常连接。		 1. 为缓存数据设置合理的 TTL。
2. 拆分大 key。
3. 检查客户端代码，确保连接池正确关闭。
应用频繁 Full GC 1. 内存泄漏（如静态集合持续增长）。
2. 堆内存设置过小。
3. 创建了大量短命大对象。		 1. 使用 jmap -histo:live 或 jmap -dump 分析堆内存。
2. 使用 Arthas 的 heapdump 命令。
3. 观察 GC 日志。		 1. 修复代码中的内存泄漏点。
2. 调整 -Xms 和 -Xmx 参数。
3. 优化代码，避免循环内创建大对象。
分布式锁失效 1. 锁过期时间设置太短，业务未执行完锁已释放。
2. Redis 主从切换导致锁丢失（Redlock 算法讨论）。		 1. 审查锁的获取、续期和释放逻辑。
2. 评估是否必须强一致，或可使用 ZooKeeper/etcd。		 1. 实现锁的自动续期（watchdog）机制。
2. 使用成熟的客户端如 Redisson。

9. 最佳实践与简历撰写建议

  1. STAR 法则精炼案例 ：

    • S (Situation) ：简短背景。如“在用户量激增后，订单查询接口 RT 飙升”。
    • T (Task) ：你的任务。如“负责定位性能瓶颈并实施优化”。
    • A (Action) ：你的行动。 这是重点 ，要具体。如“通过分析慢日志，发现 XX 索引缺失；设计了 YY 联合索引；利用 EXPLAIN 验证；在低峰期上线并灰度验证”。
    • R (Result) ：可量化的结果。如“优化后接口 P99 响应时间从 2s 降至 50ms，数据库 CPU 负载下降 60%”。

  2. 技术栈描述要具体 ：

    • 将“熟悉 Redis”改为“有 Redis 缓存设计、穿透/雪崩解决方案、分布式锁及 ZSET 排行榜实战经验”。
    • 将“了解 MySQL 优化”改为“具备 MySQL 索引优化、慢查询分析与分库分表方案设计经验”。

  3. 个人项目/开源贡献 ：

    • 如果公司项目经验受限，可以创建一个 GitHub 个人项目 。例如，实现一个简化版的秒杀系统、一个基于 Spring Cloud 的微服务 demo，并详细撰写 README，说明架构设计、技术选型和遇到的挑战。
    • 为知名开源项目（如 ShardingSphere、Sentinel）提交一个小的 bug fix 或文档改进，这会是简历上非常亮眼的一笔。

  4. 持续学习与输出 ：

    • 将你解决问题的过程、对某项技术（如 Redis 6.0 多线程 IO）的研究，整理成技术博客发布在 CSDN 等平台。这不仅能巩固知识，其链接放在简历上就是你的“技术作品集”，极具说服力。

Java 没有死，它只是进入了“强者愈强”的成熟期。市场淘汰的不是 Java，而是停留在“增删改查”层面、无法应对复杂系统挑战的开发者。补齐“高并发、高可用架构设计与实战”这块简历短板，本质上是在构建你的核心技术壁垒。从现在开始，主动揽下团队里的性能优化任务，用本文的方法论去实践、总结和沉淀。当你简历上充满了“解决”、“设计”、“提升”、“优化”这些动词，并辅以具体的数据和方案时，无论是跳槽涨薪还是晋升架构师，你都将拥有十足的底气。

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

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

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区
cover

从零开始做一个属于自己的 Skill（保姆级教程）

avatar AI编程社区