原生 <input type="file"> 无法通过 HTML 属性限制最大文件数，multiple 仅控制是否允许多选而非数量上限，必须用 JavaScript 在 change 事件中校验 input.files 长度并清空 input.value 来拦截超限。
原生 <input type="file"> 无法通过 HTML 属性直接限制“最多选几个文件”，multiple 只控制是否允许多选，不控制数量上限。真要卡死数量（比如最多 5 个），必须靠 JavaScript 拦截校验。
为什么 multiple 不等于“可限制数量”
multiple 是布尔属性，只决定 input.files 是单个 File 还是 FileList。它没有 max-files="3" 这类语法 —— 浏览器根本不认。即使写了 multiple="2" 或 multiple="false"，也等同于 multiple 存在与否，无实际效果。
- 没加
multiple：用户只能点一次、选一个，input.files.length最大为 1 - 加了
multiple：用户可 Ctrl/Cmd 多选、拖框多选、长按多选（iOS 14+ 相册），input.files.length可能为 0～N - Android 4.4 WebView 等老环境会静默忽略
multiple，行为退化为单选 —— 若需兼容，得 JS 检测input.multiple并提示降级
accept 值直接影响 iOS 多选是否生效
iOS Safari 对 accept 的解析非常严格：它不仅过滤类型，还决定调起哪个系统 App、是否显示多选 UI。写错就直接变单选，且无任何提示。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
accept="image/*"→ 调起“照片”App，支持长按多选 / “选择全部”按钮（iOS 14+） -
accept="video/*"→ 同样调起“照片”，但 iOS 16.5+ 实测常只提交第一个视频，多选不可靠 -
accept=".pdf,.docx"或accept="*/*"→ 调起“文件”App，但该 App 在 iOS 上默认禁用多选 UI（无全选、无批量勾选），用户只能逐个点 -
accept为空或未设置 → 即使写了multiple，iOS Safari 也强制单图上传 -
capture="camera"和multiple同时存在 → Apple 明确设计为互斥，multiple被静默忽略，只能拍一张
用 JavaScript 校验并拦截超限选择
核心逻辑是在 change 事件里读取 input.files，判断长度，超限则清空 input.value 并提示用户。注意 FileList 不是数组，得先转换。
立即学习“前端免费学习笔记（深入）”；
const input = document.querySelector('input[type="file"][multiple]');
const MAX_FILES = 3;
input.addEventListener('change', (e) => {
const files = Array.from(e.target.files);
if (files.length > MAX_FILES) {
alert(`最多只能选择 ${MAX_FILES} 个文件`);
input.value = ''; // 清空选择，否则下次 change 不触发
return;
}
// ✅ 合法：继续处理 files 数组
console.log('有效文件数:', files.length);
});
- 必须用
Array.from(input.files)或[...input.files]转成真数组，才能用forEach、filter等方法 - 清空
input.value = ''是关键，否则用户重复点击选择框，change事件不会再次触发（因为 value 没变） - 如需同时校验总大小，可在同一处累加
files.reduce((sum, f) => sum + f.size, 0)，再与阈值比较 - VUE/React 等框架中，避免直接操作
input.value，改用ref或useState控制，否则可能触发警告
iOS 上的多选限制不是 bug，是 Apple 的明确设计；而数量限制根本不在 HTML 规范里 —— 这两点最容易被当成“浏览器不支持”而绕弯调试。真正可靠的控制点，永远落在 JS 的 change 回调里，且必须配合 accept 的精准取值才不会在移动端失效。
