TV浏览器不支持HTML5原生带宽限制API，需通过前端切片上传+定时延时（如100KB/块、200KB/s对应500ms延迟）实现可控速率，配合服务端限速；播放端用preload="metadata"、缓冲区监控及moov前置优化加载。
TV 浏览器（如 WebOS、Tizen、Android TV 内置浏览器）本身**不提供 HTML5 原生带宽限制 API**，也无法像 PC Chrome 那样通过 DevTools 模拟限速。你不能靠 或 fetch 自动“设个 maxSpeed=200kbps”——得靠前端节流逻辑 + 后端配合来逼近目标。
用切片上传 + setTimeout 实现可控上传速率
这是 TV 浏览器上最可行、兼容性最好的方式，尤其适用于上传大文件（如用户录制的短视频）。核心是把文件切成 Blob，逐块发，并控制每块之间的时间间隔。
- TV 浏览器普遍支持
File.prototype.slice()和XMLHttpRequest.upload.onprogress，但不支持ReadableStream或AbortSignal.timeout()等新特性 - 延迟不能靠
await new Promise(r => setTimeout(r, ms))在循环里直接 await（部分 TV 引擎会卡住或忽略），改用递归setTimeout更稳 - 计算公式：若目标速率是
200KB/s，每块切100KB，则每块后延时500ms；若切50KB，就延时250ms - 注意 TV 设备内存小，切片不宜过小（
10KB会导致大量请求开销），推荐50–200KB区间
function uploadWithRateLimit(file, url, rateKbps = 200) {
const chunkSize = 1024 * 100; // 100KB
const delayMs = (chunkSize * 8) / rateKbps; // 比特换算，单位 ms
let offset = 0;
function uploadChunk() {
if (offset >= file.size) return;
const blob = file.slice(offset, offset + chunkSize);
const xhr = new XMLHttpRequest();
xhr.open('POST', url, true);
xhr.upload.onprogress = e => console.log('上传中:', Math.round((offset + e.loaded) / file.size * 100) + '%');
xhr.onload = () => {
offset += chunkSize;
setTimeout(uploadChunk, delayMs); // 下一块
};
xhr.send(blob);}
uploadChunk();
}
video/audio 播放时的“伪限速”策略
HTML5
-
preload="metadata"是 TV 浏览器最稳妥的选择，只加载头信息，不预取视频帧；preload="none"有些机型会忽略 - 监听
video.buffered和video.readyState，在缓冲区快满时调用video.pause()，等几秒再play()，形成“断续加载”效果（本质是应用层节流） - 避免使用
video.src = url直接赋值；改用video.load()+ 动态设置src，便于插入暂停逻辑 - MP4 文件务必用
moov前置（faststart），否则 TV 浏览器可能卡在 loading 状态不动——这是常见黑屏原因
Service Worker 在 TV 浏览器中基本不可用
绝大多数 TV 平台（WebOS 4.x/5.x、Tizen 5.5、旧版 Android TV）**不支持 Service Worker**，或仅支持注册但无法拦截 fetch 请求体流。别浪费时间写 SW 节流逻辑——它大概率静默失败，且无报错提示。
立即学习“前端免费学习笔记（深入）”；
- 可用检测方式：
if ('serviceWorker' in navigator)为 true ≠ 可用；需进一步navigator.serviceWorker.register()并检查 resolve/reject - Tizen 文档明确说明：Service Worker 不支持
request.body流读取，无法做上传节流 - WebOS 开发者指南警告：SW 生命周期受系统严格管控，上传类长连接常被强制终止
真正起作用的永远是「客户端切片+定时控速」+「服务端接收流限速」组合。TV 浏览器能力有限，别试图在前端做精细带宽整形——把复杂逻辑下沉到后端更可靠，前端只负责节奏协商和错误降级。
