- 博客(93)
- 收藏
- 关注
RSS订阅原创 从零实操 Spring AI 第 5 篇：准备、读取并切分知识库文档
本文介绍了构建RAG（检索增强生成）系统时处理知识库文档的关键步骤。文章强调文档质量、结构和切分方式对最终效果的影响，并提供了具体的实现方案：1）准备Markdown格式的文档目录结构；2）通过Java服务读取文档内容；3）使用分块服务进行文档切分。文中给出了核心代码框架和测试接口示例，同时预告了可能遇到的六大常见问题（如文档长度、重复内容等）。该环节为后续生成Embedding和向量检索奠定了基础，是构建企业知识库问答系统的重要数据入口。
2026-06-04 10:00:00
443
原创 从零实操 Spring AI 第 4 篇：接入 Ollama，本地也能跑模型
这篇文章介绍了如何在Spring AI项目中接入Ollama本地大语言模型。主要内容包括： 明确目标：配置Spring AI调用Ollama本地模型，实现实际功能而非概念介绍 准备工作：验证Ollama安装、拉取指定模型(qwen2.5) 实现步骤： 添加spring-ai-starter-model-ollama依赖 配置Ollama服务地址和模型参数 注意事项：列出可能遇到的问题如服务未启动、模型不匹配等 项目意义：本地模型能降低学习阶段的试错成本，为后续RAG等开发做准备 文章保持技术文章的实用风格，
2026-06-03 10:00:00
354
原创 从零实操 Spring AI 第 3 篇：流式输出、系统提示词和结构化返回
本文介绍了如何扩展AI聊天接口的三个实用功能：流式输出（改善用户体验）、系统提示词（控制AI角色行为）和结构化返回（便于业务处理）。通过代码示例展示了Spring AI中具体实现方法，包括流式接口定义、系统提示词设置和JSON结构化返回。文章强调这些功能能让AI应用更接近真实业务场景，而非停留在概念验证阶段，并提供了可能遇到的问题及解决方案。这些改进使项目向着企业级知识库问答助手的目标更近一步。
2026-06-02 10:00:00
281
原创 从零实操 Spring AI 第 2 篇：写出第一个聊天接口，再用 ChatClient 重构
文章摘要：本文介绍了如何在Spring Boot项目中调用大模型API。首先通过ChatModel实现基础聊天接口，然后重构为更灵活的ChatClient写法。核心步骤包括：1)创建返回原始消息的控制器；2)配置ChatClient Bean；3)用链式调用重构接口。文章强调实践导向，提供了完整代码示例和可能遇到的常见问题（如API密钥、编码问题等）。最终实现从用户输入到模型响应完整闭环，为后续实现流式输出和结构化返回打下基础，逐步构建企业级知识库问答系统。
2026-06-01 10:00:00
193
原创 从零实操 Spring AI 第 1 篇：创建项目，并接入 Spring AI 依赖
本文介绍了如何从零搭建Spring Boot项目并集成Spring AI的基础步骤。主要内容包括：1）使用Spring Initializr创建Java 21的Maven项目；2）添加测试接口验证框架运行；3）通过BOM方式管理Spring AI版本；4）引入OpenAI模型依赖；5）配置API密钥和模型参数。文章强调先搭建稳固的工程基础，为后续AI功能开发做准备，并列举了版本兼容、密钥管理等常见问题。最终项目具备AI能力接入条件，为开发企业知识库问答助手奠定基础。
2026-05-31 10:00:00
257
原创 从零实操 Spring AI 第 0 篇：AI 时代，我准备这样学习 Spring AI
文章摘要： 面对AI写代码的冲击，作者认为程序员应关注如何将AI能力整合到业务系统中，而非单纯焦虑职业前景。为此，作者计划系统学习Spring AI，通过构建一个企业知识库问答助手项目，逐步掌握AI应用开发的核心能力（如文档处理、向量化、多轮对话等）。该系列面向熟悉Spring Boot的Java开发者，旨在以实践驱动学习，每篇解决一个具体问题，最终实现完整功能闭环。技术栈选用Spring AI + PostgreSQL/pgvector，平衡实用性与学习成本，帮助开发者将AI能力自然融入现有Java项目。
2026-05-30 08:00:00
416
原创 仓储模式：DAO的升级版怎么用
摘要： 当需求要求订单数据同时写入MySQL和ES时，直接在Service层耦合多个DAO会导致代码维护困难。通过引入仓储模式（Repository），将数据访问抽象为领域层接口，隐藏底层实现细节（如MySQL、ES等）。仓储模式的核心优势在于： 解耦领域层与基础设施，业务逻辑不依赖具体数据库实现。 统一领域语言，提供面向业务的查询方法（如findByOrderNo），而非数据库操作。 灵活适配多存储，如同时写入MySQL、ES或缓存，只需修改仓储实现，不影响业务代码。 相比传统DAO模式，仓储模式在数据迁
2026-05-06 08:00:00
33
原创 实体vs值对象：别再傻傻分不清
摘要：实体 vs. 值对象：DDD中的核心区别与实战应用 在领域驱动设计（DDD）中，实体和值对象是两种核心建模概念： 实体：具有唯一标识（ID），生命周期可追踪（如订单、用户），通过ID判断相等性。 值对象：无唯一标识，描述特征且不可变（如地址、金额），通过属性判断相等性。 关键区别： 唯一性：实体依赖ID，值对象依赖属性组合。 可变性：实体可变，值对象需通过创建新对象实现变更。 存储：实体需独立持久化，值对象可内联存储（如订单表的地址字段）。 实战经验： 错误将值对象设计为实体会导致数据混乱（如地址修改
2026-05-04 08:00:00
24
原创 领域事件：异步下单是怎么炼成的
摘要： 订单创建接口响应时间超过5秒，排查发现8个同步操作（如发短信、邮件、通知仓库等）阻塞主流程。这些非核心操作可通过领域事件异步化解决。领域事件指业务中“值得关注的事”，发布后由订阅者异步处理，如订单创建后触发OrderCreatedEvent，短信、邮件等服务监听并执行。代码实现包含定义事件、聚合根发布事件及异步订阅处理，显著提升接口性能（从5秒降至60ms）。核心设计要素包括事件名称、数据、发布时间及订阅者，适用于解耦非关键业务逻辑。
2026-05-01 08:00:00
725
原创 你知道吗？这才是对接三方API不翻车的秘密武器
摘要：本文讲述了作者在重构支付系统时遇到的困境。虽然通过充血模型将代码从3000行精简到200行，但在对接新支付渠道时发现支付逻辑高度耦合在Service层，外部API直接侵入业务代码，导致难以维护和测试。文章以XX支付接入为例，展示了现有代码的三大问题：支付逻辑与Service强耦合、外部API直接暴露在业务层、缺乏可测试性。这正是领域驱动设计(DDD)中需要解决的问题，为后续引入防腐层(ACL)模式埋下伏笔。
2026-04-29 08:00:00
385
原创 领域驱动充血模型：Service层变薄后，我的代码终于能“呼吸”了
摘要：从贫血模型到充血模型的重构实践 本文通过一个订单取消功能的代码案例，展示了如何将臃肿的Service层逻辑迁移到领域模型中，实现从贫血模型到充血模型的重构。文章首先呈现了一个典型的贫血模型实现——200多行的OrderService方法，暴露出业务逻辑过度集中在Service层的问题。随后通过对比贫血模型和充血模型的区别，指出充血模型应同时包含属性和行为，使领域对象具备自我管理能力。最后展示了重构后的效果：Service层大幅简化，业务逻辑内聚到Order领域模型中，解决了代码臃肿、难以维护的问题。这
2026-04-26 08:00:00
30
原创 聚合根--订单和库存怎么「各管一摊」
DDD聚合根设计实战：订单与库存的跨域协作 本文通过一个电商系统订单创建时库存扣减失败的案例，深入讲解了DDD中聚合根的设计原则和跨域一致性解决方案： 问题场景：订单创建成功但库存扣减失败，导致数据不一致 聚合根本质：作为域的"老大"，统一管理域内实体的生命周期和业务规则 解决方案对比：分析了本地事务、TCC、Saga和消息队列等方案的优缺点 Saga模式实现：通过编排本地事务+补偿机制保证最终一致性 聚合设计原则： 聚合边界由业务一致性需求决定 聚合根封装业务规则（如库存校验） 通过I
2026-04-21 10:27:07
376
原创 来聊聊我为什么放弃了三层架构
摘要： 本文通过真实案例分享从传统三层架构转向领域驱动设计（DDD）的历程。在一次双11大促中，由于订单与库存逻辑高度耦合，系统崩溃暴露出贫血模型的弊端：业务逻辑散落、代码臃肿、并发能力差。作者通过DDD重构系统，将业务拆分为订单、库存、支付等独立领域，采用充血模型封装核心逻辑。改造后，领域对象自主管理状态和行为，Service层仅负责流程编排，解决了代码维护性、可测试性和高并发问题。文章用城市分区类比DDD的核心概念（限界上下文、聚合根等），强调通过职责分离和明确边界构建弹性架构。
2026-04-18 16:13:43
439
原创 你觉得面试中最难的问题是什么？
【摘要】本文围绕"金三银四"招聘季的面试经历展开讨论，邀请读者分享面试中被问过的最难问题。文章采用互动形式，鼓励用户在评论区讲述个人面试故事，并设置点赞最高者赠送【面试小册】的奖励机制。通过轻松对话的方式，旨在汇集各类具有挑战性的面试问题，为求职者提供参考和启发。（98字）
2026-03-22 08:00:00
34
原创 面试官：讲讲 synchronized的实现原理？我背了一晚上，结果还是挂了
《synchronized 底层原理与面试要点》摘要：本文深入剖析 synchronized 的底层实现机制，揭示对象头存储锁状态的关键结构（无锁/偏向锁/轻量级锁/重量级锁），详解不可逆的锁升级过程及其适用场景。通过真实案例对比对象锁与类锁的性能差异，提供优化建议（细粒度锁、减少锁持有时间等）。总结面试高频考点，包括锁区别、锁消除/粗化等JVM优化策略，并给出开发实践中的避坑指南。核心结论：synchronized通过对象头实现锁状态管理，采用自动升级机制确保并发性能，合理使用可有效提升系统吞吐量。
2026-03-20 08:00:00
712
原创 每天一道面试题之架构篇｜Java应用无感热补丁系统架构设计
文章摘要： 面试官提问关于线上系统紧急bug修复方案，探讨如何在不中断服务的情况下快速解决问题。重点考察热补丁系统的实现原理，涉及在线修复技术、系统稳定性保障等关键技术点。该问题测试候选人对高可用系统维护、实时故障处理的能力，要求具备快速响应和系统架构设计经验。（99字）
2026-01-07 09:37:02
353
原创 每天一道面试题之架构篇｜Java 热部署插件化架构设计
摘要：文章探讨了如何设计一个支持热部署和动态加载的插件系统，类似Jenkins的功能。面试官直接提问设计思路，强调系统需具备不停机更新能力。设计重点包括插件隔离机制、版本管理、依赖处理以及动态加载技术，确保插件可独立更新而不影响主系统运行。
2025-12-24 14:50:34
390
原创 每天一道面试题之架构篇｜动态功能开关（Feature Flag）系统架构设计
设计百万级用户的AB测试系统需要采用分层架构：客户端缓存功能开关配置，服务端使用分布式缓存(如Redis)存储最新配置，数据库持久化数据。通过发布订阅模式实现实时更新，采用版本号或时间戳保证一致性。系统需支持灰度发布、流量分组和实时监控，同时考虑降级策略和熔断机制确保高可用性。关键点在于平衡实时性和性能，通过多级缓存减少数据库压力，并设计完善的数据一致性方案。
2025-12-22 12:51:32
508
原创 每天一道面试题之架构篇｜分布式事务监控平台架构设计
本文探讨了微服务架构下分布式事务监控平台的架构设计。文章首先分析了分布式事务监控面临的四大挑战：跨服务调用链追踪、实时性要求、海量数据处理和复杂关联分析。随后提出四层监控架构：数据采集层（Agent探针/SDK埋点）、数据传输层（Kafka/RocketMQ）、数据存储层（Elasticsearch/ClickHouse）和数据展示层（可视化Dashboard/告警系统）。最后展示了分布式事务追踪的核心数据模型TraceSpan，包含全局追踪ID、服务调用链路、耗时等关键监控指标。该架构设计能够有效解决微服
2025-12-20 09:57:26
394
原创 每天一道面试题之架构篇｜可插拔规则引擎系统架构设计
本文探讨了如何设计可扩展的规则引擎来替代系统中的if-else逻辑。面对面试官关于代码膨胀问题的提问，文章提出通过构建规则引擎的方案来解决这一问题。该方案旨在避免条件判断语句的过度嵌套，提高代码的可维护性和扩展性。规则引擎的设计思路能够有效管理复杂业务逻辑，使系统更易于维护和扩展，是优化代码结构的重要方法。
2025-12-19 09:32:44
334
原创 每天一道面试题之架构篇｜低延迟实时排行榜系统架构设计
设计百万用户实时竞技游戏排行榜需解决低延迟和高并发问题。核心方案包括：采用Redis有序集合存储分数并实现O(1)复杂度查询；使用分布式架构水平扩展，通过分片减轻单节点压力；引入多级缓存策略减少数据库访问；采用增量更新机制避免全量排序；实现读写分离和异步处理提升吞吐量。同时需考虑容灾备份和自动扩容机制，确保系统稳定性和可扩展性。
2025-12-18 17:25:09
325
原创 每天一道面试题之架构篇｜可靠订单状态机与事务消息架构设计
电商订单状态管理面临状态一致性、事务可靠性、高并发和异常恢复等核心挑战。本文提出采用状态机设计模式，通过明确定义订单状态枚举（如待支付、已支付、已发货等）和状态转换规则，确保状态变更的合法性。同时建立状态转换校验机制，防止非法状态跳转，保证订单从创建到完成的整个流程中，各系统状态保持严格一致，避免出现支付成功但订单状态未更新等资损问题。
2025-12-17 11:18:50
353
原创 每天一道面试题之架构篇｜多租户SaaS后台系统架构设计
设计支持上千家企业的SaaS系统需重点考虑数据隔离和系统扩展性。可采用租户隔离模式：独立数据库确保数据安全但成本高，共享数据库通过schema或字段区分更经济。扩展性方面，通过微服务架构解耦功能，采用水平分库分表策略，配合缓存和异步处理提升性能。同时建立完善的监控预警机制，实现资源的弹性伸缩，确保系统稳定运行。
2025-12-15 14:49:25
533
原创 每天一道面试题之架构篇｜如何设计一个百万级短链系统架构
短链系统架构设计解析：高并发短链服务需解决百万级请求处理、全局唯一性、低延迟跳转等核心挑战。推荐采用Redis自增ID+Base62编码生成短码，结合MySQL分库分表存储。系统采用多级缓存（本地缓存+Redis）加速访问，通过302重定向实现毫秒级跳转，并集成限流、防刷等安全机制。扩展功能支持自定义短链和异步点击统计，使用分布式锁防止冲突，消息队列异步处理日志。整体架构兼顾高性能、高可用与可扩展性，满足互联网级短链服务需求。
2025-12-13 09:23:46
361
原创 每天一道面试题之架构篇｜如何设计防刷、防作弊的在线答题系统？
在线答题系统的防刷防作弊设计是典型的业务安全架构问题，需要从多个维度构建防御体系。："请设计一个在线答题系统，要求能够有效防止刷题和作弊行为，你会如何设计？：检测鼠标移动轨迹、点击间隔、答题速度的一致性。：在IP、用户、设备等多个维度设置频率限制。：分析IP地址、代理检测、网络延迟模式。：使用历史数据训练识别模型，实时评分"：每个用户获得不同的题目顺序和选项顺序。Q1：如何区分正常用户和刷题机器人？：建立IP和设备信誉库，识别恶意来源。：检测异常访问模式和题目查看行为"：检测协同作弊模式，识别攻击网络。
2025-12-12 09:32:08
412
原创 每天一道面试题之架构篇｜分库分表会带来哪些问题？深度解析与解决方案
分库分表在提升性能的同时面临诸多挑战，主要包括：分布式事务一致性（需采用最终一致性、TCC模式等方案）、跨分片查询性能问题（可通过搜索引擎或预计算优化）、全局ID生成（推荐Snowflake算法）、数据迁移复杂度（采用双写迁移策略）、关联查询困境（数据冗余或预计算宽表）以及运维监控复杂度提升。解决方案需根据业务场景权衡，如最终一致性适合大多数互联网业务，而TCC模式更适合金融系统。合理选择分库分表中间件（如ShardingSphere、MyCAT）可降低实现难度。
2025-12-11 09:34:37
959
原创 每天一道面试题之架构篇｜为什么要分库分表？什么时候需要考虑分库分表？
分库分表是解决数据库瓶颈的关键技术，主要应对单库单表面临的性能、存储、可用性和成本四大瓶颈。当数据量超过5000万行或500GB、QPS超1万、TPS超5千、连接数超1000时需考虑分库分表。典型场景包括电商订单、社交Feed流、物联网数据等海量高并发系统。分库分表能显著提升查询性能（从>100ms降至<10ms）、支持水平扩展、提高可用性，并通过量化指标模型（数据量、性能、业务增长）判断具体实施时机。方案选择需权衡分库与分表的优缺点，根据业务特点决定最适合的拆分策略。
2025-12-10 09:33:07
438
原创 每天一道面试题之架构篇|设计千万级高并发点赞/收藏系统架构
设计高并发点赞/收藏系统需解决三大核心问题：首先采用Redis集群缓存热点数据，通过分片技术应对千万级QPS；其次引入消息队列异步处理持久化，实现削峰填谷；最后结合分布式锁和CAS机制确保数据强一致性。系统架构需分层设计，前端限流、中间层缓存、后端异步落库，同时做好监控和熔断机制保障高可用性。
2025-12-09 09:48:07
266
原创 每天一道面试题之架构篇｜深入理解数据库隔离性—并发控制的基石
数据库隔离性是ACID原则的关键，确保并发事务的数据一致性。SQL标准定义了四种隔离级别：读未提交（允许脏读）、读已提交（避免脏读）、可重复读（避免不可重复读）和序列化（避免幻读）。不同级别通过MVCC或锁机制实现：读未提交无保护；读已提交使用行锁；可重复读采用MVCC或多版本快照；序列化通过范围锁完全隔离。MVCC通过版本号实现非阻塞读，写操作创建新版本。锁机制则直接控制并发访问。实际应用中需权衡一致性与性能，选择合适隔离级别。
2025-12-08 10:03:57
273
原创 每天一道面试题之架构篇｜通知型事务的致命缺陷与解决方案
摘要： 通知型事务在分布式系统中面临网络不确定性导致的数据一致性问题，典型场景包括消息发送成功但事务回滚、消息失败但事务提交等。解决方案包括： 本地消息表模式：通过数据库事务原子性保存业务数据和消息记录，异步任务定时发送并更新状态，确保最终一致性。 事务消息模式（如RocketMQ）：采用两阶段提交，先发送半消息，回调执行本地事务后提交或回滚，避免中间状态不一致。两种方案均通过可靠机制解决通知型事务的固有缺陷。
2025-12-06 09:34:14
461
原创 每天一道面试题之架构篇｜异步确保型事务——消息队列驱动的分布式事务解决方案
摘要：异步确保型事务通过消息队列实现分布式事务的最终一致性，将同步操作转为异步执行以提升性能。核心原理包括：1）本地消息表方案，确保业务操作与消息存储的原子性；2）消费者幂等处理，防止重复消费；3）定时补偿机制，处理失败消息。该模式通过解耦事务步骤，减少资源锁定时间，同时保证数据一致性，适用于高并发分布式系统。
2025-12-05 10:22:37
413
原创 每天一道面试题之架构篇｜分布式事务深度解析——柔性事务 vs 刚性事务
摘要：本文深入探讨分布式事务中柔性事务与刚性事务的区别及应用场景。刚性事务基于ACID原则，采用同步阻塞式操作（如XA协议），保证强一致性但性能较低；柔性事务基于BASE理论，通过异步非阻塞操作（如TCC、Saga）实现最终一致性。文中提供了XA协议和TCC模式的代码实现示例，分析了XA协议的性能瓶颈，并展示了Saga模式的长事务处理方案。在电商系统中，应根据业务场景选择合适的事务方案：刚性事务适用于资金交易等强一致性需求，柔性事务更适合高并发场景如订单处理。
2025-12-04 09:25:27
338
原创 每天一道面试题之架构篇|数据一致性与高性能的终极矛盾与架构权衡
摘要： 分布式系统中数据一致性与高性能难以兼得，核心矛盾源于CAP定理和物理限制（如网络延迟）。强一致性需全局锁或共识算法（如Paxos/Raft），导致较高延迟（10-100ms）；而最终一致性通过异步处理实现高性能（0.1-1ms），但存在数据延迟。实际架构常采用读写分离、多级缓存等折中方案，如电商库存系统需在"绝不超卖"（强一致）与高并发（最终一致）间权衡。该问题本质是计算机科学中的基础权衡，需根据业务场景选择最优策略。
2025-12-03 10:41:59
452
原创 每天一道面试题之架构篇｜深度解析 TCC 分布式事务及其实战应用
TCC分布式事务模型通过Try-Confirm-Cancel三阶段实现最终一致性，适用于高并发电商场景。Try阶段进行资源预留（如预扣库存、预冻结金额），Confirm阶段确认执行业务逻辑，Cancel阶段释放预留资源。相比传统2PC，TCC锁定时间短、性能更高，但业务侵入性强。在电商订单场景中，TCC可确保订单创建、库存扣减和支付等操作的原子性，通过预创建订单、预留库存和预扣金额等机制实现分布式事务控制，最终达到各服务数据一致。
2025-12-02 09:18:50
435
原创 每天一道面试题之架构篇｜线上频繁Full GC排查实战指南
摘要：本文系统讲解了Java线上服务Full GC问题的排查与解决方法。首先分析Full GC的触发条件（老年代/元空间不足等）和性能指标（频率、耗时、吞吐量），接着介绍jstat、jmap等核心监控工具的使用方法。重点提出四级排查流程：从快速状态确认、内存快照分析，到线程诊断和根因定位，最后给出内存参数优化、代码优化等解决方案。通过真实案例演示如何分析堆转储文件，识别内存泄漏对象，并提供了G1垃圾回收器的参数调优建议。
2025-12-01 09:57:41
509
原创 每天一道面试题之架构篇｜分布式Session架构设计与实战指南
摘要： 分布式Session管理是微服务架构的核心挑战，涉及数据一致性、扩展性、高可用性和安全性等问题。主流解决方案包括Session复制（如Tomcat集群广播同步）和集中存储（如Redis集群）。Redis方案通过Spring Session实现，将会话数据集中存储，支持高可用和扩展性，并可通过自定义服务管理会话创建、获取和安全属性。两种方案各有优劣，需根据业务场景权衡一致性与性能需求。
2025-11-29 09:16:20
365
原创 每天一道面试题之架构篇｜ZooKeeper 分布式锁深度解析与实战指南
“请详细说明ZooKeeper分布式锁的实现原理，对比Redis分布式锁的优缺点，并分析在实际项目中如何选择合适的技术方案。ZooKeeper作为分布式协调服务，其强一致性和丰富的节点类型使其成为实现分布式锁的理想选择。掌握ZooKeeper分布式锁的原理和实现细节，是分布式系统开发者的必备技能。
2025-11-28 09:31:19
309
原创 每天一道面试题之架构篇：Redis 分布式锁深度解析与实战指南
Redis分布式锁实现原理主要有两种方式：基于SETNX的简单方案和RedLock算法。SETNX方案通过设置键值对实现互斥，简单高效但存在单点故障风险；RedLock算法采用多节点投票机制，提高了可靠性但实现复杂。SETNX适用于单机或可靠性要求不高的场景，RedLock适合对一致性要求严格的分布式系统。两种方案各有优劣，需根据实际业务需求选择。
2025-11-26 13:59:15
311
原创 每天一道面试题之架构篇：负载均衡算法深度解析与实战应用
本文详细探讨了负载均衡算法的原理与实现，包括轮询、加权轮询、最少连接数和IP哈希等核心算法，并提供了Java代码实现示例。文章分析了负载均衡面临的四大挑战：算法选择、状态感知、会话保持和扩展性。同时给出了生产环境中的实战方案，涵盖Nginx配置和Spring Cloud集成，帮助开发者在不同场景下选择合适的负载均衡策略。这些内容为构建高性能分布式系统提供了关键技术指导。
2025-11-25 12:33:22
529
原创 困扰我一整天的MyBatis“Invalid bound statement“问题，原来是因为这个不起眼的注解冲突！
配置统一原则：相关的配置应该集中管理，避免分散在多处关注启动类：检查问题时要特别注意启动类中的注解配置理解框架机制：了解Spring Boot版本差异带来的行为变化代码审查要点：在代码审查时，要特别注意重复的注解配置。
2025-11-24 14:14:51
387
MySQL面试精粹：90%场景题深度剖析
2024-04-09
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人