fix: 优化体验

openspec/changes/add-payment-submit-guard/proposal.md

@@ -0,0 +1,26 @@
+## Why
+
+The wallet recharge confirmation, package payment confirmation, order list immediate payment, and wallet recharge order immediate payment flows can be triggered repeatedly when users tap quickly or when the page is slow to respond. This can cause duplicate order creation, duplicate payment preparation, repeated payment invocation, and inconsistent UI state.
+
+## What Changes
+
+- Add a front-end submit guard for the wallet recharge confirmation flow in `pages/my-wallet/my-wallet.vue`
+- Add a front-end submit guard for the package payment confirmation flow in `pages/package-order/package-order.vue`
+- Add a front-end submit guard for the order list immediate payment flow in `pages/order-list/order-list.vue`
+- Add a front-end submit guard for the wallet recharge order immediate payment flow in `pages/my-wallet/my-wallet.vue`
+- Standardize button behavior during submission so repeated taps are ignored until the current flow ends
+- Require submit state recovery for success, failure, cancel, validation failure, list refresh, and modal re-entry paths
+
+## Capabilities
+
+### New Capabilities
+- `payment-submit-guard`: Prevent duplicate submission in recharge and payment entry points across wallet, package order, and order list flows
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `pages/my-wallet/my-wallet.vue`, `pages/package-order/package-order.vue`, `pages/order-list/order-list.vue`
+- Affected UI flows: wallet recharge modal, wallet recharge order list immediate payment, package payment method modal, order list immediate payment
+- No backend API changes
+- No payment business rule changes

openspec/changes/add-payment-submit-guard/specs/payment-submit-guard/spec.md

@@ -0,0 +1,81 @@
+## ADDED Requirements
+
+### Requirement: Wallet recharge confirmation SHALL prevent duplicate submission
+The system SHALL prevent repeated taps on the wallet recharge confirmation button from starting more than one recharge submission flow at the same time.
+
+#### Scenario: User taps confirm recharge repeatedly during submission
+- **WHEN** the user taps the wallet recharge confirmation button multiple times before the current `confirmRecharge` flow completes
+- **THEN** the system SHALL execute only the first submission flow
+- **AND** the system SHALL ignore subsequent taps until the current flow ends
+
+#### Scenario: Wallet recharge confirmation enters submitting state
+- **WHEN** the first valid wallet recharge confirmation tap is accepted
+- **THEN** the system SHALL mark the wallet recharge confirmation flow as submitting immediately
+- **AND** the system SHALL present the confirmation button as non-repeatable during that state
+
+#### Scenario: Wallet recharge confirmation recovers after terminal outcome
+- **WHEN** the wallet recharge flow ends because of success, failure, cancellation, local validation failure, or modal re-entry
+- **THEN** the system SHALL clear the submitting state
+- **AND** the user SHALL be able to start a new recharge attempt
+
+### Requirement: Package payment confirmation SHALL prevent duplicate submission
+The system SHALL prevent repeated taps on the package payment confirmation button from starting more than one package payment submission flow at the same time.
+
+#### Scenario: User taps confirm payment repeatedly during submission
+- **WHEN** the user taps the package payment confirmation button multiple times before the current `confirmPay` flow completes
+- **THEN** the system SHALL execute only the first submission flow
+- **AND** the system SHALL ignore subsequent taps until the current flow ends
+
+#### Scenario: Package payment confirmation enters submitting state
+- **WHEN** the first valid package payment confirmation tap is accepted
+- **THEN** the system SHALL mark the package payment confirmation flow as submitting immediately
+- **AND** the system SHALL present the confirmation button as non-repeatable during that state
+
+#### Scenario: Package payment confirmation recovers after terminal outcome
+- **WHEN** the package payment flow ends because of success, failure, cancellation, validation failure, strong recharge prompt completion, or modal re-entry
+- **THEN** the system SHALL clear the submitting state
+- **AND** the user SHALL be able to start a new payment attempt
+
+### Requirement: Order list immediate payment SHALL prevent duplicate submission
+The system SHALL prevent repeated taps on an order list item's immediate payment button from starting more than one payment submission flow for the current order at the same time.
+
+#### Scenario: User taps order list immediate payment repeatedly during submission
+- **WHEN** the user taps the immediate payment button multiple times before the current `handleOrderPayment` flow completes
+- **THEN** the system SHALL execute only the first submission flow
+- **AND** the system SHALL ignore subsequent taps until the current flow ends
+
+#### Scenario: Order list immediate payment enters submitting state
+- **WHEN** the first valid order list immediate payment tap is accepted
+- **THEN** the system SHALL mark the current order payment flow as submitting immediately
+- **AND** the system SHALL present the triggered immediate payment button as non-repeatable during that state
+
+#### Scenario: Order list immediate payment recovers after terminal outcome
+- **WHEN** the order list payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
+- **THEN** the system SHALL clear the submitting state
+- **AND** the user SHALL be able to start a new payment attempt if the order remains payable
+
+### Requirement: Wallet recharge order immediate payment SHALL prevent duplicate submission
+The system SHALL prevent repeated taps on a wallet recharge order item's immediate payment button from starting more than one recharge order payment flow for the current recharge order at the same time.
+
+#### Scenario: User taps wallet recharge order immediate payment repeatedly during submission
+- **WHEN** the user taps the immediate payment button multiple times before the current `handleRechargePayment` flow completes
+- **THEN** the system SHALL execute only the first submission flow
+- **AND** the system SHALL ignore subsequent taps until the current flow ends
+
+#### Scenario: Wallet recharge order immediate payment enters submitting state
+- **WHEN** the first valid wallet recharge order immediate payment tap is accepted
+- **THEN** the system SHALL mark the current recharge order payment flow as submitting immediately
+- **AND** the system SHALL present the triggered immediate payment button as non-repeatable during that state
+
+#### Scenario: Wallet recharge order immediate payment recovers after terminal outcome
+- **WHEN** the wallet recharge order payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
+- **THEN** the system SHALL clear the submitting state
+- **AND** the user SHALL be able to start a new payment attempt if the recharge order remains payable
+
+### Requirement: Submit guards SHALL NOT change existing payment business rules
+The system SHALL preserve the current recharge validation, recharge order payment, order list payment, order creation, strong recharge decision, wallet payment, WeChat payment, toast, modal, and balance refresh behavior while adding submit guards.
+
+#### Scenario: Existing business validation remains unchanged
+- **WHEN** the user submits with an invalid recharge amount or reaches an existing payment business rule branch
+- **THEN** the system SHALL keep the current validation and messaging behavior
+- **AND** the duplicate submission guard SHALL only affect repeated-trigger protection

openspec/changes/add-payment-submit-guard/tasks.md

@@ -0,0 +1,31 @@
+## 1. Wallet Recharge Confirmation Submit Guard
+
+- [x] 1.1 Add a dedicated submitting state for the wallet recharge confirmation flow
+- [x] 1.2 Ignore repeated taps while `confirmRecharge` is already running
+- [x] 1.3 Bind the confirmation button state to the submitting state and restore it on every exit path
+
+## 2. Package Payment Confirmation Submit Guard
+
+- [x] 2.1 Add a dedicated submitting state for the package payment confirmation flow
+- [x] 2.2 Ignore repeated taps while `confirmPay` is already running
+- [x] 2.3 Bind the confirmation button state to the submitting state and restore it on every exit path
+
+## 3. Order List Immediate Payment Submit Guard
+
+- [x] 3.1 Add a dedicated submitting state for order list immediate payment
+- [x] 3.2 Ignore repeated taps while `handleOrderPayment` is already running for the current payment flow
+- [x] 3.3 Bind the order list immediate payment button state to the submitting state and restore it on every exit path
+
+## 4. Wallet Recharge Order Immediate Payment Submit Guard
+
+- [x] 4.1 Add a dedicated submitting state for wallet recharge order immediate payment
+- [x] 4.2 Ignore repeated taps while `handleRechargePayment` is already running for the current payment flow
+- [x] 4.3 Bind the recharge order immediate payment button state to the submitting state and restore it on every exit path
+
+## 5. Regression Verification
+
+- [x] 5.1 Verify repeated taps only trigger one effective submit in the wallet recharge modal
+- [x] 5.2 Verify repeated taps only trigger one effective submit in the package payment modal
+- [x] 5.3 Verify repeated taps only trigger one effective submit in the order list immediate payment flow
+- [x] 5.4 Verify repeated taps only trigger one effective submit in the wallet recharge order immediate payment flow
+- [x] 5.5 Verify users can retry after validation failure, payment cancel, payment failure, list refresh, and modal reopen