filereader 的 result 为 undefined 是因在异步操作完成前访问——readastext() 不返回 promise，必须在 onload 回调中读取；空 files、非法编码（如 gbk）、data url 提取不当、弃用 api 及大文件无提示失败是四大静默陷阱。
FileReader 读取本地文件时，result 为 undefined 是最常见问题——根本原因不是写错了，而是你试图在异步操作完成前就访问结果。
为什么 readAsText() 后立即 console.log(reader.result) 总是 undefined
因为 readAsText() 是纯异步操作，不返回 Promise，也不阻塞执行。调用后 JS 立即往下走，此时 reader.result 还没被赋值。
- 必须把取值逻辑放在
reader.onload回调里，或用reader.addEventListener('load', ...) - 别用
try/catch包裹readAsText()—— 它本身不会抛异常，出错走的是onerror - 检查
input.files[0]是否存在，空文件、用户取消、表单重置都会让files为空数组 - 编码只支持
UTF-8、UTF-16、ISO-8859-*；传'GBK'会静默失败（不是报错），reader.error可能为null，但onerror仍会触发
readAsDataURL 返回的字符串怎么提取纯 Base64 内容
readAsDataURL() 返回的是完整 Data URL，形如 data:image/png;base64,iVBORw0KGgo...，直接发给后端解码会失败。
- 正确提取：用
result.split(',')[1]拿逗号后部分 - 更稳妥写法：
const base64Str = result.includes(',') ? result.split(',')[1] : result，防意外无逗号情况 - 别用
readAsBinaryString()+ 手动btoa()—— 该方法已被弃用，且返回的字符串含控制字符，在现代 JS 中极易乱码 - MIME 类型建议从
file.type拿，比从 Data URL 字符串里解析更可靠
readAsText 和 readAsDataURL 在大文件上的实际表现差异
小文件（
-
readAsDataURL会让内存占用膨胀约 33%，一个 20MB 文件可能占 26MB+ 字符串内存，Safari 移动端容易静默失败 -
readAsText虽不膨胀，但只支持文本类文件；非 UTF-8 编码（如 GBK 日志）会乱码，浏览器不支持自动转码 - 真正要处理大文本文件（如 CSV、JSON），推荐
readAsArrayBuffer+new TextDecoder('UTF-8').decode(buffer)，比String.fromCharCode(...)安全得多 - 如果只是预览图片，
readAsDataURL一行赋值img.src = result最快；但反复读大图容易 OOM，记得手动释放img.src或用URL.createObjectURL()替代
容易被忽略的兼容性与错误兜底细节
不是所有环境都默认可用 FileReader，尤其 WebView 和老浏览器。
- 前置检测：
if (!window.FileReader)必须有，不能只靠try/catch - 必须监听
onerror，常见错误码：reader.error.code === 1（读取中止）、=== 5（编码错误） - 用户点取消、文件被其他进程占用、或
file.size === 0，都可能导致onload和onerror都不触发——加个setTimeout超时 fallback 更稳 - 移动端 Safari 对 >10MB 文件读取有时无提示失败，建议用
file.size做体积拦截，提前提示“文件过大”
真正麻烦的从来不是 API 怎么写，而是异步时机、编码边界、内存水位和静默失败这四点——它们不会报红字，但会让你花半天时间对着空白控制台发呆。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
