通知欄位要填兩個Email，第一個地址正常，一加第二個就被瀏覽器擋住，先看input是否有multiple。一般type="email"只接受一個地址；加上multiple後，可接受以逗號分隔的地址清單。分號不是這個原生欄位的分隔符號，即使某些郵件軟體使用分號，也不能直接套用。
這個設定只處理瀏覽器可判斷的格式，不證明地址存在、能收信或由填寫者持有。網站要真正把通知寄到這些地址，還需要後端解析、權限與寄送流程。先把輸入規則說清楚，訪客才不會把原本可用的兩個地址反覆修改成不同格式。
一個地址與多個地址的欄位不同
<label for="emails">通知地址</label>
<input id="emails" name="emails" type="email" multiple>
<p>多個地址請以逗號分隔。</p>這段把通知地址設成選填。如果至少要填一個地址，再加required。不要只在提示文字寫「可以填多個」，卻保留沒有multiple的input；瀏覽器不知道你的說明文字，仍會按單一地址的規則判斷。
例如[email protected]與[email protected]這兩個合成地址，可組成[email protected],[email protected]。寫成[email protected];[email protected]則不能用同樣方式通過。畫面提示最好直接展示分隔方式，避免訪客從別的系統貼上一整串時才發現不符合。
multiple也不是把資料自動提交成兩個相同name的欄位。這個input仍有自己的value，內容是一段地址清單。後端不能以為已拿到一個陣列，直接迴圈寄送；應按格式解析，再對每個項目進行你的資料驗證。
用typeMismatch核對格式問題
const input = document.querySelector('#emails');
console.log(input.value);
console.log(input.validity.typeMismatch);
console.log(input.validity.valueMissing);
console.log(input.checkValidity());在Chromium154的獨立頁面裡，沒有multiple時填兩個逗號分隔的地址，typeMismatch為true，欄位無效。加上multiple後，同一段字串的typeMismatch變成false，欄位有效。改用分號時，typeMismatch又變為true。
兩個地址之間的逗號後即使有一般空白，瀏覽器也會依email多值規則處理。在這組案例中，[email protected], [email protected]的value整理為沒有分隔後空白的形式，並通過驗證。這不表示任意奇怪字元都會被清理，也不要依賴前端去修正一份未知格式的地址名單。
檢查時可以在網路面板看真正送出的值，再和後端接收內容比較。若程式又對value做了替換或合併，問題可能出在你的轉換流程，而不是瀏覽器原生email驗證。測試用合成地址即可，不需要把真實客戶信箱放到公開截圖裡。
空欄位由required決定
沒有required時，空字串不會單靠type=email就被判成錯誤。加了required後，空值在本例的valueMissing為true，checkValidity為false。typeMismatch和valueMissing回答不同問題：前者是格式不符合，後者是必填值缺席。
因此「格式沒錯」不能代替「有填地址」。如果後端要求至少一位收件人，應明確驗證數量，不要只檢查所有已提供的項目是否看似Email，讓空清單也走到寄送流程。相反，選填通知功能則應允許使用者不提供地址，而不是暗中套入一個預設收件人。
加pattern時還有自己的限制要核對，不能假設它與multiple組合就自動表達所有公司信箱政策。像只允許某個網域、限制收件人數、禁止重複地址，這些是功能規則，應在後端有明確檢查與錯誤訊息。
後端要按每個地址處理
如果你的契約使用逗號清單，後端可以先拆分，再清理各項外圍空白，檢查每個值與總數。收到只有逗號、某項空白、任一地址格式錯誤時，應按既定規則拒絕或提示修正，不能只取第一項便宣稱其餘輸入已經處理。
收件人上限也應與介面一致。如果功能最多允許三個地址，提示應說明上限，後端則在寄送前真正拒絕超過的輸入。不要讓前端能填二十個，後端悄悄只寄前三個；使用者看不到被忽略的地址，容易把沒有收到信誤認為系統故障。
對重複地址要先決定是否合併。這裡的示範沒有提供一套通用Email正規化規則，因為地址的大小寫與服務商特殊別名可能有自己的限制。先依你的寄送服務與資料契約處理，不要為了去重把不同地址擅自改成同一個。
格式通過，不等於驗證收件人
瀏覽器不能只憑字串確認信箱是否存在。即使後端格式驗證也通過，仍可能是拼錯、停用或無法接收的地址。需要確認使用者持有信箱時，應設計適當的確認信流程；需要發送業務通知時，則要處理寄送回應與失敗紀錄。
新增多地址還可能改變通知範圍。原本只通知登入會員，若改成讓人任填多個地址，就應確認哪些資訊能寄出、誰有權新增收件人。不能因為這是一個HTML屬性修改，就忽略後端原本的資料權限。
若你不需要多收件人，保留單地址欄位反而清楚。multiple適合真的會按清單處理的功能，不宜為了讓一段錯誤輸入「看起來通過」就加上去。介面接受的內容應和後端能處理的內容一致。
提示要指向輸入方式
當格式錯誤時，提供「多個地址請用逗號分隔」比只說「資料錯誤」有用。若能指出某一項不符合，也要保留其餘已填內容，讓使用者只修正那一項。不要每次送出失敗就清空整個通知名單，逼人從頭貼上。
也可以考慮把每個地址做成獨立可編輯欄位，但那是另一種資料結構與操作設計。這篇先保留原生email多值欄位，幫你確認為何兩個地址會被擋。若之後改成多欄位或標籤式輸入，應重新核對鍵盤操作、刪除和提交資料，不沿用這次單一input的結論。
用六種輸入確認修改
若地址來自貼上，測試時也加入前後一般空白，確認畫面提示沒有誤導。不要把其他不可見字元或任意分隔符一律移除；清理過度可能把兩個原本分開的地址黏成一項。遇到不支援格式時，明確要求修改，比悄悄猜測更容易保住使用者要填的內容。
至少保存單地址、兩個逗號地址、分號地址、含逗號後空白、空選填與空必填的測試。這六種輸入能幫你分辨multiple、格式和required的責任。再把同一組合成資料送到測試後端，確認它真的逐項解析、驗證與回報。
最後核對錯誤提示和功能文件：訪客看到的是逗號規則，後端也應使用相同規則。不要讓HTML驗證、前端清理及後端寄送各自接受不同格式。維持同一套輸入約定，比不斷新增例外字元更容易讓通知功能穩定。
評論0