- 博客(54)
- 收藏
- 关注
RSS订阅原创 Agent 重试中间件到底该不该留？以 DeerFlow 为例讲清 SDK 重试与 Agent 层重试的分工
Agent 层的失败重试中间件不该被简单去掉，也不该重复底层 SDK 已经做的事。底层 SDK /：负责单次请求的瞬时故障；Agent 中间件：负责错误分类、退避预算、熔断、幂等与副作用判断、重试耗尽后的降级和可观测性。DeerFlow 的做法说明两层重试可以共存，关键在于职责清晰、预算可控、不嵌套放大。把中间件从"无脑重试"升级为"策略编排层"，它就不是冗余，而是 Agent 稳定性的重要补充。
2026-10-19 18:56:16
236
原创 LangGraph Checkpointer 封装（下）：with 的双层上下文与 MemorySaver 为什么不用 with
对 来说： 打开 sqlite 连接并构造 Saver， 关闭连接—— 就是这个连接的生命周期边界。封装里有两层上下文管理器，很多人担心 被调两次。不会，两层是完全独立的对象，各管各的： 触发的是外层生成器启动：函数体执行到内层 时，SqliteSaver 的 执行一次，然后停在 。全程只 enter 一次。 恢复生成器执行：走完 剩余代码块， 关闭连接，生成器结束。也只 exit 一次。关键机制： 是暂停点——内层 的"离开"被外层的暂停推迟了，这正是"连接在服务存活期保持打开"的实现方式
2026-10-15 19:27:55
183
原创 LangGraph Checkpointer 封装：单例、防 GC 坑与上下文管理器的真相
不必须。Python 上下文管理器是鸭子类型：只要对象实现了__enter____exit__就能用于with，不需要继承任何父类。只是类型层面的 ABC支持泛型标注），供静态标注用。生成的内部也确实继承了（contextlib 源码），但这纯属实现细节——你自己写类不继承它照样能用。因此只是"告诉类型工具它满足接口"，与运行时继承无关。
2026-10-15 19:21:37
207
原创 MQ 消费并发模型与业务防重：队列有序 ≠ 业务有序
维度RabbitMQ扩容手段加分区/队列数 + 加实例拆多队列 + 加实例顺序能力分区内天然有序，顺序消费成熟需单队列单消费者，吞吐受限适用高并发、大数据量、日志/流水业务事件、任务分发、低中并发多实例并发：多台机器分担不同任务，提升整体吞吐量单实例并发：单机多线程同时处理多条消息，提升单机吞吐量队列有序 ≠ 业务有序MQ 只能分流，不能控并发、不能控重复只要存在消息重试，就一定需要业务幂等控制。
2026-10-15 13:06:48
152
原创 LangGraph 中间件钩子时机：before_agent 与 wrap_model_call 根本不在一层
管"这一轮开跑前的 state 准备"，管"每一次模型调用的请求与响应"。需要一次性前置处理就选前者，需要覆盖每次模型调用就选后者——中间还有个，适合"每次调模型前动 state、但不需要包裹调用过程"的场景。
2026-10-14 13:53:36
167
原创 Agent 状态存储三模式：ThreadState 字段、middleware.state_schema 与实例属性
在+ 中间件架构中，共有三类存放数据的位置中心化字段去中心化声明字段中间件实例自身成员属性（装配注入，进程级配置）核心区分要点：判断数据是属于单个对话会话（thread），还是整个服务进程全局固定配置。线程级动态业务数据必须放入 AgentState；全局静态配置才使用中间件实例属性。线程级活数据进 state_schema（进 checkpoint、按 thread 隔离），进程级死配置进 self.xxx（不持久化、全局共享）。
2026-10-14 00:47:39
226
原创 Python TypedDict 与 LangGraph State 类型注解原理：软约束 vs 硬约束全解析
Python 注解对解释器是软约束，对框架可以是硬约束——关键看谁来读。TypedDict运行时就是裸dictisinstance直接抛TypeError，运行时校验只能靠或换 Pydantic。Annotatedreducer（决定合并语义）和路由函数的Literal返回值（决定分支可达性）。Pydantic state 下节点收到的是 model 实例、返回 dict；字段不能用下划线开头，否则静默变成私有属性、不进 checkpoint。路由返回值必须与path_map。
2026-10-13 16:56:02
169
原创 TypedDict 详解：LangGraph 状态定义背后的类型语法
常见说法正误正确表述1普通类的继承列表里不能写key=value，只有 TypedDict 可以❌PEP 3115 起任何类都能写（metaclass=就是），TypedDict 只是复用了这个通用机制2是"父类"❌是传给元类的配置参数，运行时落到__total__属性3定义出来的实例是某种特殊对象❌实例就是原生dict，TypedDict 从不创造 dict 的子类4想让部分字段可选，只能整个❌3.11+ 用做字段级控制，语义更准5。
2026-10-13 16:20:41
132
原创 FastAPI 协程、事件循环、Worker 模型与 Agent 项目选型终极技术复盘文档
维度OS 线程协程调度者操作系统内核用户态事件循环调度方式抢占式（可被强制切走）协作式（只在await让出）切换开销内核态上下文切换，微秒级纯用户态，纳秒级多核可利用多核并行单线程串行，用不了多核默认数量几百条即吃紧单线程可挂成千上万协程不会被系统打断，只有遇到await主动放弃执行权。协程是单线程用户态 IO 调度，不靠多线程、不靠 CPU 并行，只优化 IO 等待。FastAPI 的 async 请求不占线程，但框架仍保留40 线程兜底池伺候同步代码与依赖。
2026-10-13 15:04:06
198
原创 Python Asyncio 协程与 LLM 异步并发原理技术文档（与 Java 对比｜彻底澄清所有误区）
协程是带语法糖的用户态回调调度，单 OS 线程运行，靠await主动让出实现 IO 并发；底层 IO 100% 是回调，消灭的是回调嵌套，不是回调本身。单协程等于同步，多协程才是异步并发：总耗时从sum变max，前提是存在可重叠的等待时间。占用主线程阻塞，且每次新建并关闭 loop；独立子线程跑可实现后台异步，且天然规避跨 loop 陷阱。LLM 远程客户端应全局单例复用——但因为它持有连接池（有状态），不是因为无状态；同步 client 多线程安全，
2026-10-13 15:03:49
85
原创 LangChain / LangGraph Memory 记忆体系技术文档（作用域判定 · 官方现版本实现 · 工程坑点）
摘要是有损压缩，一旦压掉就找不回来。过度抽取 → 精度下降；抽取不足 → 召回率低。风险表现数字/ID/代码被改写摘要里"用户提到订单号"丢失了具体单号时序被压平"先做了 A 再做了 B" 压成 "做了 A 和 B"否定被吞"不要用 MySQL" 压成 "数据库选型"对策：关键事实（数字、ID、代码、时间、否定判断）必须结构化入库，摘要只用于压缩"过程性叙述"，不能作为唯一事实源。LangChain 记忆划分不依赖存储介质，核心看作用域。短期记忆绑定单一会话线程（thread_id。
2026-10-13 15:02:02
201
原创 Python 协程（Coroutine）通俗讲解与技术原理：从 await 挂起到 Agent 高并发
协程是用户态、由事件循环调度的轻量子程序；遇到await（IO 等待）时主动挂起、让出线程，线程去处理其他任务。协程跑在同一个 OS 线程内，切换开销极小，适合大量 IO 等待场景（批量调用 LLM API）。协程是协作式调度，仅在await处切换，不自动利用多核；并发需要显式开启：连续await是串行，gather才并发；并发修改共享可变变量依然存在竞态，需要；协程里不能调同步阻塞代码，否则冻结整个事件循环；
2026-10-12 16:02:46
134
原创 技术踩坑记录：CompletableFuture.orTimeout 无法终止阻塞 IO 问题复盘
Java 应用层超时无法管控内核级阻塞 IO——网络任务绝对不能只靠超时。所有网络、文件 IO 任务，超时控制必须下沉到客户端 / OS TCP 层。并发业务中「线程不回收」比「任务失败」更致命——它不报错、不告警，等发现时已经是雪崩。架构设计必须分层防护：底层管 IO、中层管异常、上层管熔断。超时预算要自上而下收敛，并且把重试次数算进去；否则上层熔断只是自我安慰。不可中断的阻塞，解除手段必须对症无效时，关闭句柄才是正解——前提是先搞清楚线程到底卡在哪。
2026-10-12 14:26:55
220
原创 Java 线程中断机制 & 优雅停机完整原理与业务坑点复盘
Java 中断是协作式的，不强制杀线程，只打标记。阻塞分三类：抛异常类（sleep/wait/join，清标记）、静默返回类（park，留标记）、完全无响应类（BIO / 锁竞争）。运行态 CPU 代码、BIO 网络 IO 完全不响应中断，必须手动判断或靠超时兜底。捕获 IE 后必须恢复标记，否则上层丢失取消信号。向上传播（throws）是首选；不能抛时才恢复标记；"延后退出"要「先记录后恢复」。简单独立阻塞任务直接退出；等待多任务的复杂场景必须连锁取消。的返回值不能被忽略，
2026-10-12 14:14:10
115
原创 ThreadPoolExecutor + CompletableFuture 组合能力复盘（含默认线程池陷阱）
"Future 编排链"在很多场景可以直接退化成"顺序阻塞代码 + 虚拟线程池"，代码更好读。这属于"能跑但不最优"的软边界，不是硬禁止。）这套组合，能覆盖后端开发里绝大多数多线程 / 异步业务场景，也是企业 Java 后端最主流的搭配。：线程池不提供编排能力，CompletableFuture 不提供资源管控能力。，各自设并发上限与队列，这才是"保护下游"的完整含义。时第 3 个任务失败就抛异常出去了，剩下的下载任务。，因为无法在编译期表达"任一类型"，一个卡住的 OSS 连接，在。
2026-10-12 09:34:24
171
原创 Executors.newFixedThreadPool 使用说明与生产风险复盘（无界队列 OOM + 手动线程池改造）
是 JDK 自带的静态工厂方法，一行代码创建固定容量线程池，底层仍是核心配置参数取值含义nThreads核心线程数nThreads最大线程数（与核心相等）0 ms见下方【修正】workQueue未指定容量 → 默认（约 21 亿）开发调试效率高，适合快速验证并发逻辑；上线生产：必须换成手动构造的+ 有界队列，理由是缺少上界 = 缺少自我保护，而不只是"会 OOM"；本项目批量 OSS 打包。
2026-10-12 08:46:26
182
原创 OSS 多文件打包回流：主链路 + 磁盘不足自动降级双链路架构设计与踩坑
这套"主链路 + 磁盘不足自动降级"的双链路架构，不是银弹，是面向资源波动场景的工程折中方案。常态优先使用落盘方案，保证性能、容错；磁盘资源不足时自动降级到管道流式方案，牺牲性能和容错换取任务不直接失败；核心前提：降级必须告警，管道仅应急，不能长期跑；链路切换只能在任务启动前，运行中无法切换；新增前提：降级前先判包体是否 > 5GB，超标直接失败；容器环境要以 Pod limit 为硬上限校验。优点：提升业务可用性。缺点：维护成本翻倍，降级链路存在较高失败代价。
2026-10-11 23:39:34
172
原创 OSS 多文件打包回流上传：流式管道无落地 VS 临时磁盘落地，两种工业方案深度对比
本身只是分片，不等于续传。方式机制手动恢复拿到未完成的uploadIdListParts列出已成功分片，从最后一片继续SDK 内置Java SDK，设；默认与待上传文件同路径，名为上传完成后自动删除每片（最后一片可 <100KB）最多10000 片单对象最大48.8TB能落盘必落盘——落盘就是稳、快、容错强；不能落盘再用管道——管道就是牺牲性能和容错，换零磁盘占用。一句话背诵版ZIP 天生串行，能并行的只有下载；磁盘方案赢在三段解耦 + 分片续传 + 无 5GB 天花板；
2026-10-11 23:07:56
193
原创 技术文档：模型工厂 `llm_provider` / `llm_use` 分层设计
通道定位主干道，预注册适配器llm_use逃生门，反射动态加载绝大多数场景使用；llm_use作为兜底扩展入口，仅用于标准化体系无法覆盖的特殊场景。两条通道可以共存，遵循统一的显式意图优先原则。字段类型说明字符串枚举预注册供应商标识（如openaivllmollama系统启动时，provider 名称与适配器实例预先注册到全局注册表llm_use类全路径字符串格式，用于动态反射导入指定适配器 / 模型类结论1负责标准化接入：绝大多数 OpenAI 兼容模型全走这个通道，是系统主力扩展方式2。
2026-10-11 23:03:05
155
原创 适配器模式（Adapter Pattern）：原理、场景与 LLM 多厂商工程落地
适配器模式（Adapter Pattern）是一种结构型设计模式，核心目的是：对多个接口不统一、行为不一致的异构第三方组件，通过包装适配，对外暴露一套统一、稳定、标准化的接口，彻底解耦上层业务与底层异构实现。通俗理解：插头转换器。不同国家插头不一样（各家大模型），电器（Agent 业务）不改代码，只换转换器（适配器）。原义补充：GoF 里适配器有两种实现形态——类适配器（多继承，同时继承 Target 与 Adaptee）与对象适配器（组合，Adapter 内部持有 Adaptee 实例）。
2026-10-11 23:02:11
90
原创 LLM 动态加载与多用户缓存架构技术文档
本文档针对 Agent 项目的动态 LLM 模型加载机制类 / 实例缓存策略多用户并发隔离方案本地缓存与 Redis 分层设计做系统性总结。问题1如何通过配置动态插拔任意 LLM 模型，无需修改业务代码2区分「模型类」与「模型实例」的缓存边界3解决多用户场景下的模型配置隔离、内存溢出、并发性能问题4明确本地内存缓存与 Redis 的分工与使用场景invoke不能用 Python 内置hash()禁止hash()：CPython 的哈希种子每进程随机化），
2026-10-10 22:13:00
209
1
原创 Python 与 Java：模块、包、对象、反射核心差异总结
模块 = 被导入后在中生成module对象的一切。文件模块：单个xxx.py包模块：带的文件夹。
2026-10-10 22:04:22
202
原创 Pydantic Field 技术文档：字段元信息、默认值与配置类工程规范
Field是 Pydantic 提供的、用于构造字段元信息对象（FieldInfo的工厂函数。作用：在模型类中为字段附加结构化元数据、默认值、校验规则；核心区分Field()返回的FieldInfo仅作为类定义阶段的元数据不会成为实例运行时的值。普通字段直接赋值（）是简化语法，Pydantic 内部会自动生成简易FieldInfo；当需要附加描述、校验、别名等扩展能力时，才显式使用Field()。版本提示：文中str | None这种新联合语法需要。
2026-10-10 15:21:36
177
原创 缓存 Key 规范与 Claude 动态/静态 Prompt Cache 机制详解
工程层缓存 Key 禁用hash()，必须用（超长再sha256），保证全局稳定且支持字典、列表结构。本地缓存只优化本地字符串拼接性能，与 Claude 云端 Prompt Cache 无关，不省 Token、不影响计费。Claude 通过动静边界分割实现云端缓存：固定系统规则为静态可缓存段，{memory}、env 信息、MCP 指令，以及 messages 流里的对话历史、工具输出、SideQuery 召回片段，全部逐轮变化、不可静态缓存。动态段变更不会破坏其之前的前缀缓存，但缓存不是永久的。
2026-10-10 15:02:48
143
原创 Python 元类、Pydantic 与魔法方法：从 dunder 到配置类一次讲透
凡是名称被前后双下划线__xxx__包裹的方法，统称魔法方法（特殊方法）。由 Python 解释器在特定时机自动触发，不需要、也不应该由开发者手动调用。写法实际调用元类__call__→→BaseModel...类定义阶段（这条语句执行时），元类扫描类命名空间：收集所有字段、类型注解、Field()配置、、各类装饰器（生成 CoreSchema：为每个字段的类型推导出一份内部模式描述（由完成）；编译出校验器 / 序列化器：把 CoreSchema 交给 Rust 引擎，得到与；挂到类上并返回类。
2026-10-10 15:02:32
162
原创 Claude Code 记忆提取与持久化机制：写链路、读链路与三处最容易被写错的地方
Claude Code 的持久记忆叫，是机器本地├── MEMORY.md # 索引，每条记忆一行，每次会话都加载├── user_role.md # 一条记忆（主题文件）├── feedback_testing.md # 一条记忆└── ... # Claude 自己创建的其他主题文件写由模型在会话期间自主决定，读由"索引预加载 + 主题文件按需读取"两级完成。写入侧：Claude 在整个会话过程中读写这个目录，用MEMORY.md追踪"什么东西存在哪个文件里"。
2026-10-09 16:45:23
73
原创 SideQuery 模块归属与概念澄清：它属于并行子任务编排，不属于记忆检索
轻量化旁路并行子任务（轻量子 Agent），由主 Agent 发起并行调用。它的定位是独立任务执行单元：有自己的上下文窗口、自己的工具集子集、自己的多步执行过程，最后只把结果摘要回灌主会话。它可按需调用各类工具，不限于记忆查询。场景说明为什么适合旁路记忆筛选从记忆索引里挑出与当前任务相关的条目检索过程本身很长，但只有结论有用代码 / 文件扫描全库搜索、批量读文件、统计符号引用中间产物（文件内容、搜索命中）体量巨大Git 信息查询变更集、blame、分支差异、历史提交检索。
2026-10-09 16:35:54
118
原创 线程本质、父子线程、线程池与事件循环异步回调：一次消除所有认知冲突的深度复盘
它不是硬件实体。不是 CPU、不是内存条、不是任何物理设备，没有物理形态。它是操作系统内核级的软件实体。具体说，是内核内存中一个真实存在、可调度、可管理的数据结构。在 Linux 上就是。资源说明独立栈内存用户栈 + 内核栈寄存器上下文CPU 执行现场，切换时要保存 / 恢复状态机就绪 / 运行 / 阻塞 / 僵死调度属性优先级、调度策略、CPU 亲和性归属关系所属线程组（tgid）、地址空间指针内核层面完全平等，无层级、无归属、无父子。差别只存在于应用层怎么用它们。
2026-10-09 14:34:40
245
原创 Agent IDE 双层异步调用机制：前端流式与后端多分支调度，到底各自解决什么问题
"读一堆东西、只把结论带回来"这件事，官方机制叫subagent官方给的例子很能说明价值：不用 subagent 时，Claude 可能读 15 个文件、跑若干次搜索，这些全部进主上下文；用了 Explore subagent 之后，这 15 次读取发生在独立上下文里，主线只记录"问题 + 摘要"。两层异步解决的是两个不同的问题：第一层（界面↔引擎）解决"不阻塞 + 可流式 + 可中断"；第二层（引擎↔LLM）解决"IO 等待时释放事件循环 + 多分支并行"。异步消除不了业务串行依赖。
2026-10-09 14:22:17
290
原创 Claude 原生 Tool 调用机制与 KV 缓存底层原理：一次讲透五个最容易混淆的问题
Tools 确实发给大模型，但走的是结构化输入通道，不进messages对话流；它仍然被分词、计入本轮请求 Token，并作为 KV 缓存的最前前缀。每轮必须全量携带 Tools，缓存只是加速计算，不替代传参。历史前缀默认全部可命中 KV，只对尾部增量做 Prefill，这是长对话低成本运行的根因。Claude 的工具调用是「结构化协议 + 约束层校验 + 分层 KV 缓存」的整套系统能力，不是简单的 Prompt 工程技巧。把第 1 条说全、说准，这篇复盘就不会被挑出硬伤。
2026-10-09 12:16:35
224
原创 Claude Code（CC）批量工具调用：并发安全分组 + Batch 执行
用 Claude Code 的时候，你可能会注意到一个现象：让它一次性读十几个文件、改几处代码，整个过程并没有明显卡顿，进度条几乎是一起往前推的。但如果换成最朴素的“一个工具调完、把结果丢回模型、模型再决定下一个”的循环，十几个工具就意味着十几轮大模型往返，每一轮都要承担一次完整的 RTT 和推理延迟。Claude Code 之所以快，核心就在于它的。
2026-10-05 15:53:22
189
原创 Mysql什么情况下行级锁会升级为表锁
行锁升级为表锁的7种场景与应对策略 数据库系统为平衡性能开销，会在特定条件下将行锁升级为表锁。主要场景包括：无索引操作、大批量处理、混合DDL/DML、外键级联、资源紧张等。常见数据库阈值不同（如MySQL约5000行）。优化方案包括：建立有效索引、分批处理数据、降低隔离级别、采用乐观锁等。监控工具可检测锁升级迹象（如MySQL的SHOW ENGINE INNODB STATUS）。合理设计可避免锁升级带来的并发性能下降问题，核心在于优化索引与控制事务粒度。
2025-07-09 17:06:45
702
原创 动态绑定的本质解析
动态绑定是面向对象编程实现多态性的核心机制，本质是通过运行时类型信息和方法表延迟确定方法实现。其实现依赖方法表机制（如C++虚函数表、Java vtable），在调用时根据对象实际类型定位方法。相比静态绑定，动态绑定具有运行时决策、类型驱动等特点，但伴随一定性能开销。该机制支撑了多态特性，符合开闭原则，现代语言通过内联缓存等技术优化其性能。不同语言实现方式各异（C++显式virtual、Java固定vtable、Python动态查找），但核心都是实现运行时的动态方法绑定，是面向对象设计的关键基础。
2025-07-09 15:39:29
422
原创 Java方法表（Method Table）详解
方法表是每个类在JVM中维护的一个方法指针数组，其中存储了该类所有可被虚调用（virtual invocation）的方法的入口地址。
2025-07-09 15:29:57
480
原创 MySQL 中的 MVCC 快照读机制详解
InnoDB的MVCC机制通过版本链、ReadView和undo log实现非阻塞的快照读，保证事务隔离性。快照读无需加锁，看到的是事务开始时的数据快照，与当前读（加锁读取最新数据）形成对比。不同隔离级别下表现不同：REPEATABLE READ保持一致性视图，READ COMMITTED能看到已提交修改。优点包括提高并发和避免读写冲突，缺点是需要额外存储维护版本。MVCC通过隐藏事务ID字段和回滚指针实现版本管理，是MySQL高并发的关键技术，但需注意长时间事务导致的undo log堆积问题。
2025-07-08 15:46:47
487
原创 数据库索引详解
数据库索引是提高查询性能的关键技术，它通过创建特殊数据结构（如B树）快速定位数据，避免全表扫描。常见索引类型包括普通、唯一、主键、复合和全文索引。优点包括加速查询和排序，缺点则是增加存储开销和降低写入速度。最佳实践建议为高频查询列建索引，避免过度索引，并定期优化。EXPLAIN命令可验证索引效果，合理使用索引能显著提升数据库效率。
2025-07-08 15:42:51
403
原创 MySQL REPEATABLE READ（可重复读） 隔离级别的锁机制
MySQL的可重复读(REPEATABLE READ)隔离级别使用复杂的锁机制，包括行锁、间隙锁和临键锁。通过MVCC实现快照读，写操作自动加行锁，SELECT FOR UPDATE可显式加锁。间隙锁解决了幻读问题，锁会保持至事务结束。与READ COMMITTED相比，可重复读的锁机制更严格，保证了更高程度的隔离性。锁基于索引工作，不当使用可能导致锁表或死锁。这种精细的锁机制是实现事务隔离的重要基础。
2025-07-08 15:28:23
655
原创 MySQL 事务隔离级别详解
MySQL事务隔离级别详解：四种标准级别分别是READ UNCOMMITTED（脏读）、READ COMMITTED（避免脏读）、REPEATABLE READ（默认级别，避免脏读和不可重复读）和SERIALIZABLE（完全串行化）。各级别分别存在脏读、不可重复读和幻读问题，隔离级别越高一致性越强但性能越低。MySQL的InnoDB引擎通过MVCC和间隙锁在REPEATABLE READ级别就实现了避免幻读。实际应用中需根据业务需求平衡一致性与性能，通常REPEATABLE READ是最佳选择。（149字
2025-07-08 11:36:34
468
原创 Spring AOP 代理与私有方法调用的关系
Spring AOP代理（JDK/CGLIB）不会代理私有方法，但私有方法仍可在原始对象内部被调用。代理仅拦截public方法：JDK代理基于接口，CGLIB代理通过子类继承。私有方法调用发生在原始对象内部，不经过代理增强逻辑。若通过反射强制调用私有方法，会完全绕过AOP增强（如事务、日志）。最佳实践是将需要增强的方法设为public，避免反射调用私有方法。如需代理私有方法，可改用AspectJ。设计时应遵循Spring规范，将需增强的方法暴露为public，私有方法仅作为内部工具使用。
2025-07-05 16:35:37
457
原创 mybatis分页插件工作原理
摘要：本文解析MyBatis分页插件的核心机制与设计思想。采用Page参数（业务层显式传递）与ThreadLocal（框架层隐式传递）的双轨制，兼顾类型安全和跨组件共享。详细说明拦截器无法直接获取Page参数的技术原因，以及ThreadLocal在分页流程中的必要性。针对常见问题提供解决方案，如分页失效原因、深度分页优化等。提出最佳实践建议：显隐结合传递参数、异步任务处理注意事项。最终提炼出"显隐结合+分层治理"的设计哲学，在类型安全与实现复杂度间取得平衡，为分页功能的使用和定制提供指导
2025-07-05 16:18:23
727
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人