diff --git a/src/views/contact-management-view.jsx b/src/views/contact-management-view.jsx
index 6d5585e8..3578c44e 100644
--- a/src/views/contact-management-view.jsx
+++ b/src/views/contact-management-view.jsx
@@ -366,7 +366,17 @@ function Verification({uid, onToast}) {
       // Patch the seed Profile will re-read on remount -- its own background getUserProfile refresh
       // can't do this for us, since a stranger-turned-pending peer still fails that gated endpoint
       // the exact same way a stranger does (server only exempts an established "friend").
-      writeCachedData('profile-seed:' + uid, {...(readCachedData('profile-seed:' + uid) || {}), relationship: 'pending_outbound'});
+      // Must also flip capabilities.can_add_friend to false here, not just relationship: Profile's
+      // canAdd render check (contact-management-view.jsx ~line 444) reads capabilities.can_add_friend,
+      // not relationship, directly. Leaving the stale can_add_friend:true (copied verbatim from the
+      // pre-request search-result seed) meant Profile kept showing an active "添加好友" button after
+      // a request was already sent -- confirmed live: send request, navigate back to this profile
+      // (the verification screen's own auto-redirect 800ms later, or its back button, both land here),
+      // and the button was still clickable, capable of firing a second, backend-undeduped request
+      // (see 新增44 in the backend issue list) purely because of this front-end staleness.
+      const priorSeed = readCachedData('profile-seed:' + uid) || {};
+      writeCachedData('profile-seed:' + uid, {...priorSeed, relationship: 'pending_outbound',
+        capabilities: {...priorSeed.capabilities, can_add_friend: false}});
       window.setTimeout(() => navigate('group-member-profile', uid), 800);
     }).catch(err => onToast(err.message || '发送失败')).finally(() => setSending(false));
   };