<object>标签本身不提供文件加载大小限制能力，需通过fetch预检响应头+后端配合实现；移动端fallback不可靠，须JS主动超时检测；真正限制应在服务端或上传环节。
<object> 标签本身**不提供任何文件加载大小限制能力**，它既不能拦截请求、也不能在下载中途终止或校验体积。所谓“限制加载大小”，实际要解决的是：防止大 PDF/Flash/SVG 等资源拖慢页面、触发内存警告，或规避移动端静默失败。真正的控制点不在 <object>，而在前端预检 + 后端配合。
为什么 object 的 data 属性无法做大小限制
浏览器解析 <object data="big.pdf"> 时，只发起 HTTP GET 请求，不暴露响应头（如 Content-Length）给 JS；你无法在资源开始传输前知道它有多大。等 load 事件触发，文件早已全部加载进插件进程或 PDF 渲染器——此时限制毫无意义。
-
onload只表示 DOM 节点就绪，不是文件加载完成 -
error事件在 PDF 加载失败时也常不触发（尤其 iOS Safari） - 无法读取
contentDocument，也就没法用 JS 检查二进制长度
可行的替代方案：用 fetch 预检 + 动态插入
想真正拦住超限文件，得绕过 <object> 的自动加载机制，先用 fetch 获取响应头判断大小，再决定是否渲染。
- 对 PDF 类资源，
HEAD请求即可拿到Content-Length（前提是服务端支持且未禁用 CORS） - 若需兼容不支持 HEAD 的后端，改用
Range: bytes=0-0发起GET，检查响应头中的Content-Range和实际长度 - 确认大小合规后，再把 URL 赋给
<object data="...">或更推荐的<iframe src="...">
示例逻辑：
立即学习“前端免费学习笔记（深入）”；
fetch(pdfUrl, { method: 'HEAD' })
.then(res => {
const size = parseInt(res.headers.get('Content-Length') || '0');
if (size > 20 * 1024 * 1024) { // 20MB
throw new Error('File too large');
}
objectEl.data = pdfUrl; // 或 iframeEl.src = pdfUrl
})移动端 fallback 失效时的兜底策略
写在 <object> 内部的 <p> 在 iOS Safari、微信浏览器里基本不显示。依赖它做“超限提示”不可靠。
- 必须用 JS 主动检测：监听
objectEl的height是否长期为 0，或设置 5s 超时定时器 - 若超时未渲染，手动移除
<object>，插入自定义提示文案和下载链接 - 对已知大文件（如报表），直接跳过
<object>，用<a download>强制下载
真正该限制大小的地方是服务端或上传环节
前端限制只是体验层防护，关键防线在后端：
- OSS/对象存储配置生命周期或上传策略（如 PostObject 的
content-length-range字段） - Nginx 用
client_max_body_size限制上传体，proxy_buffering off配合流式响应头 - API 接口返回前校验文件元信息，对 >50MB 的 PDF 直接拒掉并返回
413 Payload Too Large
用户看到白屏或卡顿，往往不是因为没加限制，而是把限制逻辑错误地绑在了 <object> 这个根本无权干预网络层的标签上。
