本篇为《UniswapV2 深入解析》系列第 23 篇，聚焦于 协议费用（Protocol Fee） 的设计理念、合约落地与治理流程，并对整个系列进行总结回顾。在前文中，我们已经完成对 Router、Pair 以及闪电贷安全机制的梳理，本篇将进一步完善“收益分配”这一闭环，帮助读者理解 Uniswa

本篇为《UniswapV2 深入解析》系列第 22 篇，延续上一章对闪电贷流程与手续费模型的讨论，聚焦于 闪电贷引入的重入风险 及其治理方案。阅读本文前，建议先回顾第 20 与 21 篇对手续费修复与闪电贷机制的梳理，以便理解本文中合约架构的演进脉络。

继第 20 篇讨论手续费修复之后，本篇将围绕 Pair 合约，介绍闪电贷能力如何与手续费验证逻辑融合。阅读本篇后，你将理解闪电贷的业务场景、合约设计要点、实际实现方式以及 Foundry 测试策略。

上一章我们验证了精确输出场景的价格计算，本篇回到 Pair 合约，针对长期被忽视的手续费缺口进行全面修复，确保自动做市恒定乘积模型不被破坏。 原始的 swap 函数虽通过恒定乘积检查限制输出，却没有对输入资金征收 0.3% swap 手续费，导致流动池实际增值低于预期，进而影响价格稳定性与协议收入

延续第 18 篇对“精确输入兑换”的分析，本章聚焦另一条常被忽略的路径：用户提前锁定想要获得的输出数量，再推导出所需投入的最小代币金额。这类“反向兑换”在做市调仓、偿还借贷仓位或撮合做空头寸时尤其重要，也完整展示了 Router 与 Library 协同的另一面。

本篇第 18 篇延续上一章对 Router 的讨论，聚焦最常见的兑换入口 swapExactTokensForTokens。前端几乎所有“用固定数量兑换尽可能多目标代币”的需求都会落到这条路径上，因此理解其执行流程是把握 Uniswap 交互体验的关键。

继第 16 篇聚焦 LP 授权后，本篇将深入交换流程的数学基础，阐述输出金额的推导、实现与验证方法，并给出多跳路径下的滑点治理策略。

本篇聚焦移除流动性流程中的授权细节，解释为何 Router 需要代用户持有 LP 代币并执行 _safeTransferFrom，以及在生产环境下如何通过 approve 与 permit（EIP-2612）降低交互成本并提升安全性。内容基于仓库现有的 Solidity 0.8.30 实现与 Fo

在上一章中我们完成了 Router 的流动性添加流程。本篇继续沿着“端到端流动性管理”这一主线，聚焦于 LP 代币销毁的安全性 与 流动性移除（removeLiquidity） 的设计方案。我们将先回顾历史上的漏洞案例，再分析当前仓库中 UniswapV2Pair 的实现细节，并给出 Router

本篇围绕 UniswapV2Library 展开，它是 Router 在执行流动性操作与代币兑换时的关键依赖。相比上一章对 Router 主流程的拆解，本文将聚焦于库函数的设计理念、源码实现细节以及与 Router 的联动方式，帮助读者彻底理解“无状态辅助合约”在 UniswapV2 架构中的作用。