iOS Safari从iOS 13起禁用iframe加载PDF，属系统级硬性限制，无法绕过；替代方案是使用<object>标签嵌入PDF，可在iOS Safari中正常调用内置预览器。
iframe 加载 PDF 时，默认就是显示第一页——只要 PDF 能正常加载，根本不用额外操作。
为什么有时候“不显示第一页”？
所谓“没显示第一页”，其实是加载失败、跳转被干扰或 URL 被覆盖导致的假象：
- PDF 文件路径错误（如 404 或返回 HTML 登录页），
iframe白屏或显示下载提示，根本没进 PDF 渲染流程 - URL 末尾意外拼接了
#page=2或#nameddest=xxx等参数，强制跳转到其他位置 - 服务端设置了
Content-Disposition: attachment，浏览器直接触发下载，不渲染 - iOS Safari 对 iframe 内 PDF 的处理较特殊：可能缓存旧状态、忽略部分参数，甚至只渲染首帧后卡住
确保第一页出现的最小可行写法
最干净、最不容易出错的方式就是只写基础 URL，不加任何锚点参数：
<iframe src="report.pdf" width="100%" height="600"></iframe>
注意以下三点：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
report.pdf必须是可直连的 HTTP/HTTPS 路径，不能是file://或后端重定向后的地址 - 服务器响应头必须包含
Content-Type: application/pdf，且不能有X-Content-Type-Options: nosniff干扰解析 - 如果 PDF 在跨域 CDN 上，需确认该域名已配置 CORS 允许
GET请求（否则白屏无报错）
想“显式强调第一页”反而容易翻车
加 #page=1 看似稳妥，但实际没必要，还可能引入问题：
- 某些旧版 PDF 查看器（如 IE + Adobe 插件）对
#page=1支持不稳定 - 移动端 Safari 有时会把
#page=1当作新导航触发重载，造成闪烁或空白 - 如果 PDF 本身设置了打开动作（OpenAction），
#page=1可能被忽略或冲突 - 更隐蔽的坑：URL 已含 fragment（比如
doc.pdf#zoom=80），再拼#page=1会导致 fragment 覆盖，变成doc.pdf#page=1，丢失缩放设置
真正需要干预的，不是“怎么显示第一页”，而是“为什么第一页压根没出来”——优先查网络请求状态码、响应头和控制台是否报 CORB 或 blocked by CORS。一旦 PDF 流正确送达浏览器，第一页就是默认且唯一可见的起始画面。
