- 博客(71)
- 收藏
- 关注
RSS订阅原创 让 Agent 拥有“无限记忆“：对话压缩中间件的工程化实现
本文介绍了 agentscope-harness 中 CompactionMiddleware 的实现方案，旨在解决长对话 Agent 面临的上下文窗口限制、注意力衰减和成本爆炸问题。该方案采用三层渐进式压缩（参数截断、工具结果裁剪和 LLM 总结）、链式总结和双层长期记忆（日账本和精选记忆），在有限上下文窗口内保持对话一致性。核心流程包括拆分系统消息、动态配置解析、渐进式压缩触发判定，以及记忆抽取、会话落盘和内容蒸馏等步骤，确保关键信息不丢失的同时控制对话规模。
2026-08-10 15:02:01
352
原创 AgentScope 2.0 × Langfuse：Agent 全链路追踪的一次讲清
本文介绍了如何通过OpenTelemetry + Langfuse实现对AgentScope 2.0项目的可观测性集成。主要内容包括： 选择Langfuse作为可视化平台，采用OpenTelemetry标准协议而非私有SDK，避免供应商锁定 整体架构设计：通过两个中间件协作，OtelTracingMiddleware生成标准Span，LangfuseEnrichmentMiddleware补充专有属性 依赖配置：引入OpenTelemetry核心组件，通过application.yaml集中管理配置
2026-08-06 09:38:52
482
原创 AgentScope 2.0 工具加载机制：Skills、MCP 与自定义 Tools 的一次讲清
本文介绍了AgentScope 2.0在构建AI Agent时如何通过Tool、MCP和Skill三种能力实现工具扩展。项目基于Spring Boot框架，通过分层架构将工具与Agent解耦，核心配置集中在config包。文章详细分析了技术栈版本、代码结构、关键约定，并提供了装配链路速查图，展示了从启动到对外暴露接口的完整流程。AgentScope通过Tool（本地方法）、MCP（跨语言协议）和Skill（指令包）三类能力的统一管理，为LLM提供了灵活的扩展机制。
2026-08-04 15:33:23
422
原创 Palantir Foundry 核心建模体系：构建企业级智能知识图谱的基石
本文系统解析了Palantir Foundry数据智能平台的五大核心组件：ObjectType（对象类型）为数据赋予业务语义，LinkType（链接类型）构建实体关系网络，ActionType（操作类型）实现分析到行动的闭环，Functions（函数）提供智能计算能力，Interfaces（接口）解决多态建模难题。这五大组件协同工作，将传统孤立数据转化为可理解、可关联、可操作的动态知识图谱，帮助企业构建与真实业务同步的数字孪生。平台通过语义化建模、关系定义、智能计算和操作执行的四层架构，有效解决了数据孤岛、
2026-05-22 16:08:47
782
原创 一文吃透OpenClaw日志系统：级别、配置、优先级，全程无废话
OpenClaw日志系统基于tslog构建，提供多级别日志管理能力。系统支持7种日志级别（silent至trace），通过数值大小控制日志过滤机制。默认级别根据环境自动适配：生产环境为info，测试环境为silent。配置支持四种方式：配置文件定义（支持独立设置文件和控制台日志）、环境变量覆盖（OPENCLAW_LOG_LEVEL）、命令行参数（--verbose提升至debug级别）以及运行时API调用。核心解析流程遵循环境变量>配置文件>默认值的优先级顺序，并针对测试环境进行了特殊优化处理。
2026-05-06 09:08:34
451
原创 基于Transformer的医疗文本科室分类模型开发全流程
本项目成功构建了基于Transformer的医疗文本科室分类模型，实现了患者病情文本到就诊科室的精准映射，模型准确率高、推理速度快，可应用于医疗咨询分诊、智能问答等场景。通过HF镜像解决了数据集下载问题，通过合理的模型设计与超参数配置，确保了模型的性能与泛化能力。后续可进一步优化模型结构、扩大数据集规模，提升模型对复杂病情文本的分类精度，同时完善Flask服务，适配生产环境部署需求。
2026-04-29 08:48:51
417
原创 模型调用、记忆机制到多模态：LangChain 与 Spring AI 深度对比
摘要：本文对比了LangChain与SpringAI两大AI开发框架的核心特性。LangChain基于Python生态，强调组件可组合性，支持链式调用、智能体、工具等概念；SpringAI则基于Java生态，采用Spring风格抽象，注重依赖注入和声明式配置。二者在记忆管理、模型调用、提示词、工具调用、持久化、向量数据库等核心功能上各有特色：LangChain灵活性高但学习曲线陡峭，SpringAI则更符合企业级开发习惯。代码示例展示了两个框架在模型调用、记忆管理、工具定义等场景下的典型用法，为开发者选择合
2026-04-28 07:49:57
447
原创 源码编译 OpenClaw 必看：微信插件安装避坑手册，告别 429 限流 + 命令报错
本文记录了在Windows11环境下从源码编译运行OpenClaw AI助手框架并安装微信插件的完整过程。主要解决了三个关键问题：1)源码编译版需使用pnpm openclaw命令而非全局安装；2)因ClawHub限流需切换国内npm镜像；3)正确的插件安装启用流程。文章详细说明了安装步骤、配置修改及问题解决方案，特别强调了源码编译场景下的注意事项，为开发者提供了实用的参考指南。
2026-04-14 07:59:06
1039
原创 一张照片 + 一段音频，免费Sonic生成真人级数字人视频
Sonic是一个基于音频的人像动画生成系统，能够将静态图片与音频结合生成对口型动画。本文详细介绍了环境搭建步骤：1)安装FFmpeg并配置环境变量；2)克隆项目并创建Python虚拟环境；3)安装依赖包和预训练模型。针对常见问题提供了解决方案，包括依赖安装超时、模型下载失败、CUDA内存不足等问题的处理方法。特别针对低配显卡给出了优化建议，如降低分辨率、减少推理步数或使用CPU模式运行。完整的环境配置指南可帮助用户快速部署Sonic系统并解决常见运行问题。
2026-04-08 09:27:31
510
原创 OpenClaw（小龙虾）源码部署详细步骤：Node+Git+Bash 一站式
摘要：本文介绍OpenClaw项目在Windows系统下的环境配置与运行指南。要求Node.js≥22.12.0，推荐使用v24.14.0版本。针对多版本Node共存问题，提供了临时环境变量设置方法（CMD/PowerShell/Bash）。详细说明了Git Bash的安装步骤及使用场景，特别解决了Windows下bash命令报错问题。项目构建流程包括：设置高版本Node路径、验证环境、安装依赖(pnpm)、UI构建等步骤。最后给出OpenClaw的GitHub资源地址及完整的编译启动流程，包含API配置和
2026-04-02 12:01:11
847
原创 com.mongodb.MongoCursorNotFoundException: Query failed with error code -5 and error message ‘Cursor
MongoDB MongoCursorNotFoundException（错误码 - 5）的成因与解决方案。该异常是因客户端访问的游标在服务端已失效，主因是游标闲置超 10 分钟被自动清理。MongoDB 通过ClientCursorMonitor后台线程每隔 60 秒扫描，CursorManager的timeoutCursors方法依据cursorShouldTimeout_inlock逻辑，判定闲置超阈值（默认 10 分钟）且未被使用的游标，将其从哈希表移除并释放资源，后续客户端操作该游标即触发异常
2026-03-23 09:43:05
439
原创 mongodb全表读取数据，随机I/O vs 顺序I/O分析
摘要：测试显示带过滤和排序的MongoDB查询(SQL2)比全表扫描(SQL1)慢5.6倍。根本原因是：1) SQL2使用depid索引导致4000万次随机I/O(1MB/s)，而SQL1是顺序I/O(134MB/s)；2) depid哈希值与时间物理分布不匹配，加剧随机访问；3) 中间结果超出内存限制引发磁盘排序。虽然两者处理文档数相同，但SQL2的索引扫描+回表操作累计开销巨大，特别是机械硬盘上随机I/O性能极差，导致查询时间从32分钟增至3小时。
2026-03-20 09:27:50
425
原创 MongoDB $in查询参数上限是多少个？
MongoDB的$in操作符参数上限受BSON文档16MB默认限制（源码MessageSettings定义，实际校验含16KB头空间）。理论上int类型可放约419万个值，但实测平均每个int值占用12字节（含类型标识1字节+索引字符串键名7字节+结束符+int值4字节）。类似地，Long类型理论可放209万个值，实测占用16字节。该限制源于BSON数组元素需要额外存储类型和索引信息。建议开发者根据实际编码逻辑预估上限，避免因超量导致查询失败。
2026-03-10 09:39:26
471
原创 int c = a报错NullPointerException，为什么呢？
本文分析了Java中自动拆箱引发NullPointerException的原因及解决方案。通过Integer赋值给int的案例，揭示了自动拆箱本质是调用intValue()方法，当Integer为null时就会抛出NPE。反编译字节码验证了这一机制，并列举了所有包装类的拆箱方法对应关系。核心解决方案是在拆箱前进行判空处理，给出默认值或业务逻辑兜底。文章提供了优化后的代码示例，帮助开发者规避此类问题。
2026-03-04 09:25:36
375
原创 Tool Calling 技术实战：解决大模型时间感知问题
摘要：本文介绍了通过ToolCalling技术解决本地部署的Qwen3:1.7b模型获取实时时间的问题。传统调用方式因模型训练数据时效性限制，返回错误时间（2023年）。解决方案通过定义DateTimeTools工具类，使用@Tool注解标记获取当前时间的方法，并注册到模型工具列表中。测试显示，工具调用后返回准确时间（2026-01-30T22:45:30.123456），验证了该技术在扩展大模型实时信息获取能力方面的有效性。该方案具有松耦合、可扩展等架构优势，为AI应用的动态能力提升提供了技术支撑。
2026-02-26 09:44:30
764
原创 Spring AI + MongoDB + 本地小模型构建 RAG 系统：代码解析向量算分与小模型痛点分析
本文介绍了一个基于Java+SpringAI框架实现的轻量级RAG问答系统，用于故障编码解释场景。系统包含四大核心模块：MongoDB连接配置、向量存储实现、向量检索配置和本地小模型连接。核心功能包括知识库初始化、向量检索和RAG问答，通过手动实现余弦相似度计算实现向量比较。测试表明，该系统虽然实现了私有化部署，但存在小模型输出格式控制差、结果不稳定等缺点。建议优化向量存储方式、升级模型规模并改进Prompt设计以提升系统实用性。该方案适用于简单内部场景，但难以满足生产环境的高要求。
2026-02-11 09:27:53
665
原创 企业级 RAG 实战：基于 Spring AI + MongoDB 构建智能数据检索系统
本文详细介绍了基于SpringAI框架和MongoDB向量搜索实现企业级RAG（检索增强生成）方案的全过程。主要内容包括：1）核心技术栈选择，使用SpringAI简化开发流程，MongoDB实现向量存储与检索；2）环境配置与核心依赖引入；3）关键编码实现，包括文本向量化、向量存储、相似度检索等核心环节；4）完整RAG流程演示，通过语义匹配增强大模型回答准确性。该方案有效解决了企业私有数据问答和知识精准匹配需求，相比传统ES检索更能理解语义关联。文章提供了从环境搭建到核心代码的完整实现指南，为企业落地RAG应
2026-02-03 09:36:30
712
原创 基于Spring AI+本地大模型+MongoDB实现私密化与记忆能力-企业级免费大模型应用
本文提出了一种基于SpringAI框架的企业级大模型本地化部署方案，通过Ollama工具本地部署DeepSeek/Qwen等开源大模型，结合MongoDB实现对话上下文持久化存储。该方案采用分层架构设计，包含数据存储层（MongoDB）、模型服务层（Ollama+本地大模型）、应用框架层（SpringAI）和业务接口层，既保障了企业核心数据不流出内网，又通过文档数据库实现了大模型的"长期记忆"功能。关键技术实现包括：1)使用SpringAI统一管理大模型调用和上下文组装；2)MongoD
2026-01-26 09:44:38
1172
原创 告别在线大模型数据泄露风险：Ollama 本地化部署全指南（适配企业私密数据场景）
Ollama是一款开源跨平台工具，简化本地大语言模型（LLM）的部署与管理。它支持Windows/macOS/Linux系统，通过极简命令实现模型运行、下载和管理，无需复杂配置。核心特性包括隐私优先的本地离线运行、硬件自动适配和丰富的模型支持（兼容30+主流开源模型）。提供安装目录自定义、模型版本管理、后台服务控制等功能，并支持创建和分享自定义模型。常用命令包括ollama run启动模型、ollama list查看本地模型、ollama pull下载模型等，大幅降低LLM使用门槛，适合需要数据隐私和离线场
2026-01-19 10:08:30
1319
原创 Java+MySQL时区难题-Date自动转换String差8小时
文章分析了MySQL查询中出现8小时时区偏差的问题。当使用字符串类型参数时，JDBC驱动不做时区处理，导致MySQL按自身时区解析产生偏差；而Date类型参数会被驱动基于serverTimezone=UTC配置自动转换时区。通过检查操作系统、MySQL和JVM的时区设置，发现关键在于JDBC驱动对不同类型的处理方式：字符串参数"裸传"不转换，Date参数会经过时区适配。建议优先使用Date/Timestamp类型参数，确保驱动层完成正确的时区转换，避免时间偏差问题。
2026-01-13 10:37:51
1146
原创 MySQL 5.7 大表删除部分数据：.ibd 文件会变小吗？磁盘会释放吗？
MySQL中执行DELETE语句删除部分数据后，表空间文件(.ibd)不会自动缩小，磁盘空间也不会释放给操作系统。这是由于InnoDB引擎的设计机制：删除操作仅标记空间为"空闲"供后续复用，不会物理回收空间。要真正释放空间，必须重建表结构，推荐使用OPTIMIZETABLE命令（会锁表）或在业务低峰期执行表重建。对于日志类大表，建议采用分表策略（如按天/月分表），通过删除整个分表来高效释放空间，避免锁表风险。
2026-01-04 09:44:01
1039
原创 踩坑记：MySQL 连接 URL 缺失useCursorFetch参数引发的 Java 内存溢出惨案
摘要：Java后端服务因MySQL连接参数配置不当引发OOM故障。问题根因是缺失useCursorFetch=true和defaultFetchSize=10000参数，导致JDBC默认一次性加载千万级结果集到内存。解决方案包括：1)修改连接URL添加游标和分批参数；2)设置合理fetchSize值(建议1000-10000)。关键经验：大数据量查询必须启用游标模式，并根据数据规模调整fetchSize，避免内存溢出或性能下降。
2025-12-30 09:34:17
1293
原创 MySQL错误日志的核心是 InnoDB 缓冲池耗尽 + 海量行锁导致数据库崩溃
MySQL数据库因InnoDB缓冲池内存耗尽导致崩溃。主要问题是一个全表更新事务持有6397万行锁，占用121MB内存（缓冲池仅128MB），触发系统保护机制强制终止。错误链：无索引的全表更新→过量行锁→内存耗尽→I/O过载→数据库崩溃。解决方案包括：1）分批更新数据；2）增大缓冲池至8GB；3）为department_id添加索引。关键参数innodb_buffer_pool_size当前为128MB，建议动态调整为8GB以支撑大规模操作。
2025-12-22 09:42:11
985
原创 SQL没有limit 1读取一条findFirst竟让 800 万数据涌入内存导致系统崩溃
JBoot/ActiveRecord 的findFirst并非优化查询逻辑，而是先通过find方法全量加载结果集到内存，再截取第一条 —— 当满足条件的数据有 800 万条时，所有数据都会被解析为Department对象存入 List。内存雪崩：800 万Department实例 + 关联的字符串、HashMap 等对象，直接耗尽堆内存，触发持续 Full GC，系统失去响应。
2025-12-15 09:47:57
958
原创 mongod的aggregate中$last不同查询条件返回顺序不一致原理分析
db.user.explain().aggregate([ { $group: { _id: null, lastDoc: { $last: "$name" }, lastValue: { $last: "$age" } } } ]) $match条件写法不同，$last返回数值顺序不不同。开始认为是代码bug，后来深入研究mongodb机制才发现是query策略不同，数据顺序不同，$last结果就不一致。第五步：聚合函数，不写参数，对上面6条数据进行$last计算。
2025-12-09 09:50:52
465
原创 MongoDB B+树的存储能力与层级查询：三层B+树能存多少数据？
本文探讨了MongoDB三层B+树索引的存储能力与线上环境查看方法。通过分析B+树结构特点，在假设索引页4KB、数据页32KB、索引项20字节条件下，计算出三层B+树理论可存储约8522万条记录。实际存储量受索引字段类型、数据大小等因素影响。查看树层数可通过db.getCollection().stats()命令，获取"maximumtreedepth"等参数。文章还详细解析了索引配置参数如internal_page_max、leaf_page_max的含义，并强调实际应用中需结合业务场
2025-12-02 09:39:40
843
原创 mongodb根据索引IXSCAN 查询记录流程
摘要：MongoDB索引查询采用IXSCAN+FETCH两阶段执行模式。IXSCAN阶段通过B+树索引快速定位符合条件记录的RecordID，时间复杂度为O(logn)；FETCH阶段根据RecordID获取完整文档。这种设计类似图书馆先查目录再取书，避免了全表扫描。普通索引叶子节点仅存储索引键值和RecordID，不包含完整文档数据，通过职责分离（IXSCAN处理索引、FETCH获取文档）实现高效查询。执行计划分析显示，查询"age":30时先扫描索引获取RecordID，再根据Rec
2025-11-25 09:34:50
1208
原创 MongoDB使用的是 B+树，不是你们以为的 B树
B树和B+树是多路平衡查找树的核心区别在于数据存储方式：B树所有节点存储键值对，而B+树仅叶子节点存储完整数据，非叶子节点仅作索引。B+树通过叶子节点链表实现高效范围查询，树高更低，磁盘I/O更稳定，适合数据库场景；B树查询路径可能提前终止，但范围查询效率较低。MongoDB的WiredTiger引擎实际采用B+树结构，虽官方文档可能简称为B树。二者的选择取决于具体场景对单点查询和范围查询的需求差异。
2025-11-18 09:42:39
1146
原创 一文搞懂计算机数据类型：字节占用与存储原理
本文系统梳理了编程中数据类型的字节占用规律和存储机制。关键点包括：1）数据类型字节数受语言和系统位数影响，如C/C++中long在32/64位系统分别占4/8字节，而Java固定long为8字节；2）存储方式采用二进制补码，正数存原码，负数需取反加一，确保运算统一性；3）实际开发需注意语言差异，合理选择数据类型以平衡内存开销和数值范围。掌握这些底层知识对优化程序性能和调试内存问题至关重要。
2025-11-11 09:32:16
1267
原创 扣子（Coze）工作流玩转古人名字剧本创作：超实用提示词攻略
摘要：本文介绍了运用扣子工作流创作历史人物剧本的方法。通过"古人剧本创作提示词"框架，从角色定位、技能要求、输出规范四个维度，系统化还原历史人物形象。该方法要求精确标注人物性别、民族信息，以编年体形式梳理6个关键事迹，确保历史真实性与叙事完整性。最终生成包含人物生平、标题、性别、民族等信息的JSON格式文件，为剧本创作提供标准化框架。以李白为例，展示了从出生到逝世的关键事件及文学成就的完整梳理过程。
2025-11-04 09:37:14
1425
原创 mongodb为什么默认不使用速度更快的hash索引？反而使B+树索引
MongoDB默认使用B+树索引而非哈希索引的原因在于综合性能考量。哈希索引虽在精确查询时具备O(1)优势，但存在三大缺陷：无法支持范围查询（如age>20）、不能直接用于排序操作、不支持复合索引的前缀匹配。而B+树索引通过有序存储特性，既能高效处理点查询（O(logn)），又能完美支持范围查询、排序和复合查询，成为数据库应对多样化查询场景的理想选择。这种设计权衡体现了工程实践中的通用性优先原则。
2025-10-29 10:47:00
758
原创 mongodb有主键_id，为什么生成系统字段$RecordId？
MongoDB中的$recordId是存储引擎(WiredTiger)使用的内部物理标识符，用于定位文档在磁盘上的位置。与用户可见的_id字段不同，$recordId是系统自动生成且可能随文档移动而变化的。通过showRecordId()方法可查看该隐藏字段。MongoDB查询时，会先通过_id索引找到对应的$recordId，再根据$recordId定位实际文档数据。IDHACK查询优化策略直接利用_id索引快速定位$recordId，提高查询效率。$RecordId数值类型自增，记录每次插入都是顺序插入
2025-10-24 09:51:38
1028
原创 扣子（Coze）文案→图片→视频工作流：剪映小助手正确下载、草稿同步及无 VIP 导出教程
本文介绍了使用扣子（Coze）搭建工作流后，如何正确下载草稿并合成视频的完整流程。关键点包括：1）识别匹配的剪映小助手（需与插件同源）；2）设置剪映小助手与剪映软件的草稿同步路径；3）下载工作流草稿；4）通过复合片段操作实现无VIP导出视频的技巧。重点解决了常见下载失败问题，并提供了从草稿路径查找到最终导出成片的详细步骤，帮助用户绕过VIP限制完成视频制作全流程。
2025-10-20 09:45:37
9237
4
原创 扣子（Coze）搭建 工作流（文案→提示词→图片→视频）详细步骤
在扣子（Coze）平台搭建多节点工作流需遵循五步流程：创建工作流→添加节点→配置参数→串联逻辑→试运行发布。核心环节包括：1）通过大模型节点实现文案生成和提示词优化；2）使用图像流节点生成图片；3）通过插件或大模型将图片转化为视频。关键配置要点包含：正确引用上游节点输出作为输入参数、设计精准的提示词指令、确保节点间逻辑串联。测试阶段需验证各节点输出是否符合预期，支持通过选择器节点实现条件分支等进阶优化。
2025-10-14 09:38:16
15945
2
原创 MongoDB源码delete分析oplog：从删除链路到核心函数实现
MongoDB oplog实现机制分析 摘要：本文深入分析了MongoDB操作日志(oplog)的核心实现机制。oplog作为固定大小的capped集合(local.oplog.rs)，是MongoDB副本集数据同步的关键组件。文章详细解读了从文档删除操作到oplog记录的完整调用链，包括CollectionImpl::deleteDocument、OpObserverImpl::onDelete到最终logOp的调用过程。重点剖析了logOp方法的核心逻辑：输入验证、OpTime分配、并发控制以及通过_l
2025-10-10 09:29:15
982
原创 MongoDB源码分析慢日志：从配置到实现的完整解析
摘要：MongoDB慢日志通过Profiling机制实现，支持三级配置：0（关闭）、1（记录超过slowms阈值的操作）、2（记录所有操作）。核心实现流程包括：1）会话状态流转处理请求；2）handleRequest方法执行命令并计算耗时；3）completeAndLogOperation方法通过shouldDBProfile判断是否记录（基于profile级别、slowms阈值和sampleRate采样率）。验证结果显示，当执行时间超过配置的50ms阈值时，操作详情会被记录到db.system.profi
2025-09-29 09:29:07
1148
原创 MongoDB源码delete分析观察者getOpObserver()-＞onDelete
本文分析了MongoDB删除操作db.user.deleteOne({"age":2828})的执行流程和底层实现机制。删除过程采用DELETE>FETCH>IXSCAN策略，通过DeleteStage、FetchStage和IndexScan阶段协同完成。核心实现包括： 使用WriteUnitOfWork确保删除操作的原子性 通过OpObserver机制监听删除前后事件，支持复制、审计等功能 删除操作会记录到oplog中，实现数据同步 事务处理支持多文档操作的回滚和提交 该
2025-09-23 09:40:45
1045
原创 MongoDB源码delete分析DeleteStage过程的WriteUnitOfWork事务
本文分析了MongoDB执行deleteOne操作时的底层事务机制。该操作采用DELETE>FETCH>IXSCAN策略，通过DeleteStage、FetchStage和IndexScan阶段协同完成。核心事务控制由WriteUnitOfWork类实现，包含四个关键步骤：1)创建事务单元并加锁；2)执行文档删除；3)提交事务；4)异常时回滚。MongoDB通过Locker管理锁资源，RecoveryUnit实现事务原子性，WiredTiger引擎处理底层事务提交/回滚。整个过程严格遵循ACID
2025-09-16 09:20:45
910
原创 Cursor和Hbuilder用5分钟开发微信小程序
快速开发微信小程序只需5分钟！使用Hbuilder和Cursor两个工具：1)下载Hbuilder创建uniapp项目；2)运行到小程序模拟器；3)安装Cursor并用自然语言描述需求生成代码；4)预览效果并上传微信平台。特别演示了wifi二维码识别功能开发，通过详细指令让Cursor自动生成包括界面设计、弹窗提示等完整代码，大幅提升开发效率。
2025-09-09 09:33:28
1842
1
原创 MongoDB源码delete分析CmdDelete过程collection()-＞deleteDocument
MongoDB的deleteDocument方法是实现文档删除的核心函数，主要流程包括：检查集合类型（拒绝固定集合删除）、获取文档快照并触发前置观察事件、可选保存删除文档副本、从索引目录移除记录、执行底层存储引擎删除操作，最后触发后置事件并更新调试指标。该方法严格遵循先索引后数据的删除顺序，并通过WiredTiger存储引擎实现具体删除操作，同时支持变更流等特性所需的删除文档存储功能。整个删除过程被包裹在事务中，确保操作原子性和一致性。
2025-09-02 09:19:57
766
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人