FileReader 无法直接读取任意本地路径，仅支持用户主动选择的文件；须用 FileReader 异步读取，readAsText() 适合文本，readAsDataURL() 适合图片预览，大文件需分片或流式处理，且必须在 onload 回调中获取 result。
FileReader 读取本地文件内容并渲染到页面
浏览器无法直接访问用户本地文件系统，必须通过 FileReader 在前端完成读取和解析。这不是“上传到服务器后再读”，而是纯前端即时解析——用户选中文件后立刻转成文本/HTML/图片等，无需后端参与。
常见错误是试图用 fetch 或 XMLHttpRequest 直接请求 file:// 路径，这在现代浏览器会被跨域策略拦截，且路径不可靠。
- 只支持用户主动触发的
<input type="file">事件获取的File对象 -
FileReader的readAsText()适合 .txt、.json、.html 等文本类；readAsDataURL()更适合图片、PDF（需配合<img>或<iframe>） - 读取大文件时注意内存占用，
readAsArrayBuffer()可配合流式解析，但复杂度高
读取 HTML 文件并在页面内安全显示
如果用户上传的是 .html 文件，想“在线阅读”即渲染其结构，不能直接用 innerHTML = reader.result，否则会执行其中的 <script>、触发外链请求，存在 XSS 风险。
安全做法是剥离脚本、限制作用域：
立即学习“前端免费学习笔记（深入）”；
- 用
DOMParser解析字符串为文档，再遍历移除所有script、iframe、on\*属性 - 将解析后的
body内容插入一个带sandbox属性的<iframe>（如<iframe sandbox="allow-same-origin">），隔离执行环境 - 若仅需展示源码而非运行效果，用
textContent或hljs.highlightElement()做语法高亮更稳妥
PDF 文件怎么不发请求就预览
PDF 无法被 FileReader 直接转成可渲染 HTML，但现代浏览器支持用 URL.createObjectURL(file) 创建临时 URL，交由内置 PDF 查看器处理。
关键点在于：这个 URL 必须传给 <iframe> 或 <embed>，且生命周期要手动管理：
- 每次新文件都要调用
URL.revokeObjectURL()清理旧地址，否则内存泄漏 - 部分浏览器（如 Safari）对
objectURL中的 PDF 支持不稳定，可降级为 base64 字符串（data:application/pdf;base64,...），但超 2MB 易卡顿 - 不要尝试用
fetch(fileUrl)再渲染——fileUrl是 blob 协议，fetch不支持跨协议读取
Chrome 和 Edge 能打开本地 HTML，Firefox 不行？
这是 Firefox 的主动安全策略：它禁止从 blob: 或 file: 上下文加载子资源（比如 HTML 里的 <img src="xxx.png">），即使图片也在同一 FileList 中。Chrome/Edge 默认允许，但行为不一致。
解决思路不是绕过策略，而是提前提取依赖：
- 若 HTML 引用了同目录图片/CSS，需用
FileReader分别读取这些文件，再用URL.createObjectURL()替换 HTML 字符串中的路径 - 简单场景下，建议限制只读单文件（如纯 HTML 文档无外部引用），或转为打包成 data URL 格式
- 真要完整模拟本地文件系统行为，必须走服务端（如用
http-server临时起服务），已超出“纯前端在线阅读”范畴
真正难的不是读文件，而是处理 HTML 里隐含的资源依赖和执行上下文——这点很容易被忽略，直到用户上传一个带图片的笔记页面，发现只有空白框。
