E2.15.2pre-choice file constraints设计
格式与大小限制需在选择前告知
别名: 上传限制事前告知 · accept attribute · 选完才说文件太大
概念解释
人在打开文件夹之前就要知道「这里收什么」：类型、最大体积、张数。选完甚至传完才弹出「不支持 .heic」「超过 5 MB」，等于让人做完一次无效劳动。选择前约束（pre-choice file constraints）把规则写在接收区上，赶在系统选择器和拖入之前。它管的是限制出现的时刻，不是点选和拖入要不要并存，也不是失败之后如何重试。
机制
挑文件是带成本的搜索：回忆文件名、翻目录、等缩略图。约束若在搜索之后才出现，成本已经付了，失败体验还附带「早说啊」。事前可见的类型和大小会改搜索策略：人直接去找 PDF、先看体积。系统选择器的 accept 能灰掉不合法类型，但大小很少在选择器里过滤，更要在页面上写清。手机相册默认出 HEIC、截图很大，不事前说明就会稳定撞上这两类拒绝。约束还要与真实后端一致；页面写 10 MB、网关 2 MB，事前告知变成谎言。
边界
类型极宽（「任意附件」）时，列出所有 MIME 是噪声，写「常见办公格式，单文件上限」比清单有用。安全扫描只能在上传后做，病毒这一条无法事前保证，应分开说「传上去之后还会检查」，不要假装选择前已经穷尽。浏览器对 accept 的尊重程度不一，灰掉不等于拦死，事前文案仍要能被读到。从即时通讯「分享到 App」进来的文件没有经过你的接收区，约束要在落地页再亮一次。
怎么落地
- 在选择按钮和拖放区旁边写清类型、大小、数量，不要把第一次告知留给红字。
- 让
accept与文案一致，并在客户端于选择后立即用同一规则再检查体积。 - 用用户能懂的说法（「PDF 或 JPG，每个不超过 5 MB」），不要只丢 MIME 串。
- 验证：不选文件，只问「这里能传什么」。答案对不上真实拒绝规则，约束就还藏在失败里。再故意选一个超限文件，看拒绝发生在上传开始前还是进度条走完之后。