Maple提款仍在队列：核请求编号、部分处理、自动与手动收款
链小知 · 进阶 · 核验 · 依官方文档整理
按已有提款记录逐请求对照shares、FIFO、处理方式和接收结果；区分取消返还LP与兑付底层资产，不套旧提款窗口。
开始前准备
- 准备已有Portfolio Withdraw请求、原Pool与WithdrawalManager地址/版本、requestId和owner、请求份额、处理/取消回执、原接收记录及时间。
- 本任务按当前Queue正文及固定2382e406源码解释。原实例版本无法对应时仅核页面记录，不用新调用或签名验证。
1. 确认请求入口和实际提款机制
官方当前入口为app.maple.finance/earn/portfolio，余额右侧Withdraw产生提款请求。核原记录是否对应syrupUSDC/USDT及同链Pool/Queue；只出现按钮或输入金额不代表请求交易成功。
当前Queue没有循环提款窗口，isInExitWindow返回true只为兼容，不证明立刻有可用资产。历史Cycle教程、Queue默认自动处理和手动模式要分开；无法辨认原manager就暂不判断何时可领。
检查结果：原请求对应同链同池和Queue机制，历史窗口未套给当前队列。
2. 逐请求核owner与份额数量
按原RequestCreated或请求记录保存requestId、owner和shares原值。当前版本同一owner可有多个请求；requestsByOwner返回编号与份额数组，requestIds仅取最后一项，不能用一个编号或redeemRequested布尔值代表全部请求。 Frontend将requestRedeem第二参数标receiver，但固定Pool实际是owner（份额来源）；不能照标签把它换成任意收款地址。
请求以shares表达并将LP移至manager保管，availableBalance是资产口径。钱包LP减少不自动是损失或已收到USDC；先对原请求份额、保管和接收对象，未取到编号不补成功请求。
检查结果：每条请求的编号、owner和shares独立可追溯，资产数值未当请求份额。
3. 区分排队、部分处理和处理时汇率
FIFO按可用流动性先处理较早请求；一条请求可部分处理，余下份额保留原队列位置。已有RequestProcessed要同时核事件ABI的shares（已处理份额）、assets（对应资产原量）与请求尚余shares，不因一次事件或队列编号前移标全部完成。
兑换按处理时含未实现损失的池汇率，申请时估值不锁价。24小时、不到2天、最多30天等官方叙述属于不同页面的条件预期，不能据此承诺期限；无流动性/具体处理记录时只记等待或待核。
检查结果：已处理与未处理份额之和可对原请求；汇率和时间没有用预期代替实况。
4. 核自动与手动分支，不默认另claim
默认自动模式在处理时兑换并直接把资产给owner，无需用户另发领取交易。若原资料显示isManualWithdrawal或ManualWithdrawalSet，则处理可能只是增加manualSharesAvailable，之后手动redeem才是兑付；RequestProcessed本身不够证明该分支已收款。
固定实现的lockedShares只对应手动可用份额，自动队列中该值为0不能推出没在排队。普通用户不能仅靠页面选择将manager改为手动；缺模式记录时保留自动/手动未核，不照通用ERC-4626教程重复提交withdraw。
检查结果：处理模式与原兑付证据对应，手动可用shares和全部排队shares未混合。
5. 对照已有减少或取消记录
若已有取消/减少操作，当前removeSharesById要求调用者是该请求owner，数量不超过当前请求shares；全部移除取消请求，否则余项留在原位置。核返回/事件所指LP份额及原钱包返还，不把请求消失称为USDC退款。
固定错误WM:RSBI:INVALID_REQUEST、NOT_OWNER、NO_CHANGE或INSUFFICIENT_SHARES分别提示对象、权限、零量或份额不符；只有原错误才定位，不建议为排错再次取消。管理员移除和用户取消权限不同。
检查结果：减少/取消与LP返还可对应，未把取消或删队列记录标资产赎回。
6. 核处理后实际资产和费用
对已有成功兑付保存网络、资产完整标识、owner接收地址、RequestProcessed的assets原值（processExit返回的resultingAssets是另一种方法记录）和转账结果；部分批次逐条汇总。同一钱包余额变化可能含其他转账，不能直接当本次队列收款额。
原请求Gas、借贷/策略费用、二级市场兑换的费用和滑点不同。官方提现页称排队继续interest至处理，Frontend FAQ却称请求后yield stops；当前正文冲突保留，不能用任一说法保证等待期间收益。
检查结果：提款资产、接收结果和费用有同笔依据；计息冲突未被擅自统一。
7. 按阶段完成等待或异常诊断
结论分未有成功请求、仍排队、部分已处理、手动份额已准备但兑付未核、自动处理收款已核、取消LP已返还或资料不足。原LOW_LIQUIDITY、暂停、转账失败需按实际manager和回执核，失败记录不补成0或已领。
DEX卖出Syrup是另一条成交路线，受市场价、滑点和费影响，不等队列兑付。请求、processing、估值及成功交易各保留自己的证据，最终只以正确资产/接收记录判断收款。
检查结果：每条请求处于明确阶段或未知，没有立即退出或兑付保证。
怎样确认完成
- 每个requestId有请求、部分处理/模式、取消或收款的独立对照。
- 未读取真实队列/执行redeem/取消/资金接收，documentation范围保持明确。
常见错误与边界
- RequestProcessed在手动分支可只增加manualSharesAvailable；未兑付不标到账。
- 取消返还的是LP份额；有时间窗口的旧说明不覆盖当前Queue。