フォームを二回押すと二重注文になるか
収録 2026-11-05
フロントの防止は表面だけ。サーバーが重複要求に耐える必要がある。
これは私の注文・送信の流れです：[流れの説明]。二重送信のリスクを確認してください：1）ユーザーが重複して起こせる経路（連打、更新、戻って再送信、ネットワーク再試行、複数端末）を挙げる；2）フロントのデバウンスやボタン無効化が防げる範囲と、防げない範囲を分ける；3）サーバー側の冪等化（冪等キー、一意制約、状態遷移での検査）と、それぞれの適用限界を示す；4）重複要求が来たとき、在庫・金額・通知が二回実行されないか確認する；5）必ず足すテストケース；6）正常系でしか防げていない箇所を指摘する。「ローディングを出す」だけで済ませないこと。
当サイトオリジナル
中国語の原文
置き換えるプレースホルダー 1
括弧の中をご自身の情報に置き換えてから送ってください。
[流れの説明]
使い方
重複の判断基準は「同じ要求が二回到達したとき、二回結果が出るか」で見る。
こう変えてみる
- コードを書く前に要件と制約を復唱させる。
- 全体書き換えではなく、最小の変更とロールバック方法を出させる。
得られる成果物
- そのまま使える最小変更（コピー可能なコード）
- 影響範囲：変更ファイルと追従が必要な呼び出し元
よくある失敗
- 一度に十ファイル変更させ、何が原因か分からなくなる。
- エラーだけ貼ってコードとバージョンを省くと、使えない修正が返る。
出力のチェック
- 変更は動いて戻せて、無関係なコードに手を入れていない。
- 境界条件（空・巨大・同時実行）が説明かテストで押さえられている。
使いどころと注意
- 向いている用途：要件と制約を復唱させてから、最小限の動く変更を出させる。
- 注意：エラーにはバージョンと最小再現を添える。無いと一見もっともらしいが合わない修正が返る。