面试题手册

优化 Chrome 网络请求，先用 DevTools Network 找慢在哪里。一次请求会经历 DNS、TCP/TLS、排队、TTFB、下载等阶段；不同阶段慢，处理手段完全不同。TTFB 高通常是后端或网关慢，下载慢可能是资源太大，排队多可能是连接数、优先级或主线程阻塞。追问HTTP/2 以后还要合并 JS 和 CSS 吗？不一定。HTTP/2 多路复用降低了小请求连接成本，过度合并反而会让缓存失效范围变大。preload、prefetch、preconnect 怎么选？preconnect 提前建立跨域连接；preload 抢首屏关键资源；prefetch 适合空闲加载下一页资源。Network 面板看哪些指标？先看瀑布图是否有长串阻塞，再看 Timing。TTFB、Content Download、Queueing 分别对应不同问题。缓存策略怎么避免旧资源？HTML 用短缓存或协商缓存；带 hash 的 JS、CSS、图片可设置长强缓存。没有版本号的资源不要随手缓存一年。写段代码<link rel="preconnect" href="https://cdn.example.com" crossorigin><link rel="preload" href="/assets/app.abcd.js" as="script">

Chrome 拦截跨域是同源策略在保护用户数据。协议、域名、端口任意一个不同就算跨域；前端可以发起请求，但浏览器会在读取响应时检查 CORS 头。真正的解决点通常在服务端：明确允许哪些来源、方法、请求头，是否允许携带 Cookie。开发环境可以用代理绕过限制，生产不要靠关闭安全策略或插件。追问CORS 和 JSONP 有什么区别？CORS 是标准跨域机制，支持多种方法和预检；JSONP 只利用 script 标签，只能 GET，安全边界差。为什么有些请求会先发 OPTIONS？带自定义请求头、非简单方法或特殊 Content-Type 时，Chrome 会先发预检请求确认服务端是否允许。携带 Cookie 时为什么不能写 *？如果 credentials: include，服务端必须回显具体 origin，不能是星号，还要设置 Access-Control-Allow-Credentials: true。开发代理和服务端 CORS 怎么取舍？本地代理适合调试；上线后要让网关或应用服务配置 CORS，因为开发服务器代理不会跟着用户浏览器上线。写段代码res.setHeader('Access-Control-Allow-Origin', 'https://www.example.com');res.setHeader('Access-Control-Allow-Methods', 'GET,POST,OPTIONS');res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');res.setHeader('Access-Control-Allow-Credentials', 'true');

Chrome 的内存管理主要由多进程架构、Blink 渲染管线和 V8 垃圾回收一起完成。每个标签页、iframe、扩展或站点隔离进程都可能占用独立内存；JS 对象由 V8 管，DOM、样式、图片、GPU 资源则不完全在 JS 堆里。所以排查内存问题不能只看一个数字，要分清是 JS 堆增长、DOM 节点泄漏，还是图片、Canvas、WebGL 资源没有释放。追问V8 垃圾回收大概怎么工作？V8 会把对象分成新生代和老生代，短命对象优先在新生代快速回收，存活久的对象会晋升到老生代。最常见的内存泄漏有哪些？定时器没清、事件监听没移除、全局数组当缓存、闭包引用大对象、已删除 DOM 还被 JS 变量保存，都是高频原因。Chrome DevTools 怎么排查？先用 Performance 或 Task Manager 观察内存是否持续上升，再到 Memory 面板拍 Heap Snapshot，对比 Retained Size 和 Detached DOM tree。WeakMap 能解决所有泄漏吗？不能。它适合存跟对象生命周期绑定的附加信息，但如果外部还有全局引用，WeakMap 也救不了。代码里应该怎么清理？组件卸载时清理事件、定时器和订阅，长列表做虚拟滚动，大图和 Blob URL 用完释放。const timer = setInterval(sync, 5000);window.addEventListener('resize', onResize);return () => { clearInterval(timer); window.removeEventListener('resize', onResize); };

Service Worker 是运行在页面之外的浏览器脚本，Chrome 用它来做请求拦截、离线缓存、推送通知和后台同步。它不直接操作 DOM，也不是一直常驻后台线程，而是被 install、activate、fetch、push 等事件唤醒，处理完任务后可能被浏览器回收。理解它的关键不是背 API，而是记住：它站在页面和网络之间，但生命周期由浏览器控制。追问Service Worker 和普通 JS 脚本有什么区别？普通 JS 跟着页面走，页面关闭脚本就结束；Service Worker 注册后独立于页面。它不能访问 window 和 DOM，需要用 postMessage、Cache Storage、IndexedDB 与页面协作。install、activate、fetch 分别做什么？install 适合预缓存静态资源，activate 适合清理旧版本缓存并接管客户端，fetch 决定请求走网络还是缓存。缓存策略怎么选？静态资源通常 cache first，HTML 入口常用 network first 或 stale-while-revalidate，接口数据按业务新鲜度决定。更新为什么经常“不生效”？Chrome 发现 sw.js 字节变化后会安装新版本，但旧页面仍被旧 worker 控制，新版本要等旧页面关闭才激活。必要代码长什么样？下面只是兜底示例，真实项目要区分静态资源、HTML 和接口。self.addEventListener('fetch', event => { event.respondWith(fetch(event.request).catch(() => caches.match(event.request)));});

Chrome 支持 PWA，靠的不是某个“打包开关”，而是浏览器把 Web App Manifest、Service Worker、HTTPS、安装入口和权限能力串在一起。页面先要像普通网站一样可访问，再通过 manifest 告诉 Chrome 应用名称、图标、启动地址、显示模式和主题色；Service Worker 负责接管部分网络请求，让核心资源可以缓存，弱网或离线时仍有可用界面。追问Chrome 判断网站能不能安装成 PWA 看什么？通常要有 HTTPS、有效 manifest、合适尺寸图标，以及可被 Service Worker 控制的页面。安装提示还会结合用户访问行为，不是文件写好就立刻弹窗。Manifest 里最容易漏掉什么？常见漏项是 start_url、scope、display 和 192/512 尺寸图标。scope 配错会让用户从图标打开后跳回普通浏览器标签页。离线能力是不是把所有接口都缓存起来？不是。HTML 壳、CSS、JS、图标适合预缓存；用户数据、价格、库存、权限状态更适合网络优先或短缓存。更新 PWA 时有什么坑？Service Worker 更新不是刷新就立即生效，新 worker 要等旧页面关闭后才接管，除非主动调用 skipWaiting 和 clients.claim。最小实现需要哪些代码？页面注册 Service Worker，worker 在 install 阶段缓存核心资源，fetch 阶段兜底返回缓存。生产还要加版本号和清理旧缓存。if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js');}

Chrome 的 GPU 加速主要发生在合成阶段：页面先经过样式计算、布局、绘制，再把部分内容交给 GPU 作为合成层处理。它能让 transform、opacity 这类动画更顺，但不是所有属性都适合丢给 GPU；如果滥用，反而会增加显存、纹理上传和合成成本。追问哪些 CSS 更容易触发 GPU 合成？常见的是 transform、opacity，以及部分 filter、视频、Canvas、固定定位元素。开发里通常用 transform 做位移和缩放，不要用 left、top 频繁改位置。will-change 是不是越多越好？不是。它只是提前告诉浏览器这个元素可能要变，浏览器可能因此提前建层和分配资源。动画结束后应移除。GPU 加速为什么有时反而变慢？合成层不是免费的，层太多会占显存，内容变化频繁还会导致纹理反复上传。低端设备最容易出问题。怎么确认页面真的用了合成层？用 DevTools 的 Layers、Performance 和 Rendering 工具。看是否有大量 Layout、Paint，或异常多图层。写段 CSS.card { will-change: transform, opacity; }.card.is-moving { transform: translate3d(0, 12px, 0); opacity: .92; }

Chrome 调试的核心不是把 DevTools 每个面板都点一遍，而是按问题类型选工具：样式错看 Elements，请求慢看 Network，逻辑异常看 Sources，卡顿掉帧看 Performance，内存上涨看 Memory。这样排查更快，也不容易在 Console 里靠猜。追问Elements 面板适合解决什么问题？它适合查 DOM 结构、CSS 覆盖关系、盒模型尺寸和最终计算样式。要注意样式可能来自媒体查询、伪类、继承和组件库默认规则。Sources 断点怎么用才高效？普通断点查确定位置，条件断点只在某个参数或状态出现时暂停，XHR/fetch 断点适合追接口是谁发起的。Network 面板看哪些字段？先看 Status、Method、Initiator、Payload、Response，再看 Timing 里的 DNS、SSL、TTFB 和下载耗时。性能卡顿从哪里开始录？用 Performance 面板录制真实操作，重点看 Main 线程长任务、Layout、Recalculate Style 和 Paint。

Chrome 的隐私保护不是只开无痕窗口就够了。无痕模式只能让本机不保留历史记录、Cookie 和表单数据，网站、公司网络、运营商仍然可能看到访问行为。真正有用的做法，是把 Cookie、网站权限、安全浏览、密码检查、同步数据和扩展权限一起管起来。追问无痕模式到底保护什么？它主要保护这台设备上的痕迹，比如浏览历史、临时 Cookie、搜索记录和表单输入。它不等于匿名上网。第三方 Cookie 要不要全部禁用？多数情况下建议阻止第三方 Cookie，因为它们常用于跨站跟踪。遇到老旧登录或支付异常时，可以只给可信站点加例外。哪些权限最容易被忽略？位置、摄像头、麦克风、通知、剪贴板和后台同步最容易被随手允许。通知权限尤其要定期清理。扩展程序会不会破坏隐私设置？会，尤其是申请“读取和更改所有网站数据”的扩展。安装前看权限，安装后清理不用的扩展。

Astro View Transitions 的核心是：页面仍然按多页应用导航，但 Astro 在跳转时拦截链接、获取新页面、替换 DOM，并借助浏览器 View Transitions API 做过渡动画。它给静态站带来接近 SPA 的切页手感，但不等于把站点变成完整 SPA；SEO、静态输出和按页加载的优势仍保留。追问View Transitions 和 SPA 路由有什么区别？SPA 通常只替换客户端状态和组件树。Astro 更像增强版 MPA 导航，新页面仍是单独文档，只是在切换时接管加载和替换过程。为什么脚本状态会丢？导航后 DOM 会被替换，旧节点上的事件和第三方实例可能不存在。需要在 astro:page-load 里重新初始化必要脚本。transition:name 有什么边界？同一次过渡里名称应当唯一。列表页要用 slug 或 id 拼接名称，不要所有卡片都叫 cover。什么时候不该使用页面过渡？表单提交、支付、登录回调、后台管理不适合花哨动画。内容站、作品集、相册更适合，但也要控制范围。写段代码<ViewTransitions /><img src={post.cover} transition:name={`cover-${post.slug}`} />

Astro 做 SEO 的优势不在插件多，而在默认输出更接近搜索引擎喜欢的页面：静态 HTML、少 JavaScript、首屏快、内容能直接被爬虫读到。落地时重点不是堆满 meta，而是保证每页有唯一标题、稳定 canonical、准确 description、可分享 OG、合适结构化数据，以及能被发现的 sitemap。追问Astro 为什么比很多 SPA 更适合 SEO？Astro 默认把页面渲染成 HTML，爬虫不需要等客户端 JavaScript 执行完才看到正文。但如果正文依赖客户端接口再拉取，仍可能被漏抓。Meta 标签是不是越多越好？不是，title、description、canonical、OG 和必要的 Twitter Card 通常就够了。每页唯一、准确、和正文匹配更重要。sitemap 和 robots.txt 有哪些坑？最常见的是 site 没配，导致 sitemap 生成错误域名；robots.txt 不提升排名，只控制抓取边界。SEO 组件放 layout 还是页面？基础标签可以放 layout，但标题、描述、发布时间、文章类型必须由页面传入，避免大量页面共用同一 description。写段代码<title>{title}</title><meta name="description" content={description} /><link rel="canonical" href={url} /><script type="application/ld+json" set:html={JSON.stringify(schema)} />

VPN 变慢不要先怪节点，先把问题切开看：本地网络、VPN 协议、服务器距离、加密开销、MTU 分片和运营商干扰，任何一环都可能拖慢速度。最稳的排查顺序是先关掉 VPN 测下载、上传、延迟和丢包，再打开 VPN 测同一组数据。追问怎么判断是 VPN 慢，还是本地网络慢？关掉 VPN 测速，再打开 VPN 测同一地区、同一时间段的速度和延迟。裸连也慢，多半是 Wi-Fi、路由器或宽带问题。WireGuard 为什么通常比 OpenVPN 快？WireGuard 协议更轻，代码路径短，常用 ChaCha20，加密开销更低。OpenVPN TCP 容易出现重传叠加，网络一抖就卡。MTU 为什么会影响速度？VPN 会额外加包头，原本能通过的包可能变大后被分片。常见做法是把 MTU 从 1500 降到 1420 或 1400，但不要盲目降太多。Split Tunneling 什么时候有用？只有部分应用需要 VPN 时，分流能降低延迟和带宽压力。边界是安全策略要清楚，敏感请求不要被错误拆到不同路径。写段命令speedtest-cli --simpleping -c 50 your-vpn-server.comiperf3 -c your-vpn-server.com -t 30

MariaDB 和 MySQL 同源，但现在已经不能简单当成同一个数据库的两个名字。MariaDB 最初由 MySQL 原始作者创建，目标是保持开源和兼容，同时加入更多存储引擎、优化器能力和集群方案；MySQL 由 Oracle 维护，生态稳定，云厂商支持广，MySQL 8.0 在窗口函数、CTE、JSON、权限模型等方面也补齐了很多能力。追问MariaDB 能直接替换 MySQL 吗？低版本和常规 SQL 场景通常迁移成本不高，客户端协议、基础语法和常用工具大多兼容。真正要小心的是高版本差异、系统表、复制、JSON 行为和认证插件。两者功能主要差在哪里？MariaDB 提供 Aria、ColumnStore、Spider、MyRocks 等更多引擎选择，也有自己的 Galera 集群路线。MySQL 8.0 的数据字典、JSON、窗口函数、CTE 和权限体系更统一。性能上 MariaDB 一定更快吗？不一定。读写性能受版本、引擎、索引、SQL、参数和硬件影响很大，同一条 SQL 在两个优化器里的执行计划可能不同。生产环境怎么选？如果团队重度使用 MySQL 8.0、依赖云厂商托管能力，继续用 MySQL 更稳。如果看重开源路线、特定引擎或 MariaDB 生态，MariaDB 合适。写段 SQLSELECT VERSION();SHOW VARIABLES LIKE 'version_comment';EXPLAIN SELECT * FROM orders WHERE user_id = 1001;

MariaDB 的存储引擎不是越多越好，而是要按事务、读写比例、数据规模和运维成本来选。默认优先 InnoDB，因为它支持事务、行级锁、崩溃恢复和外键，适合绝大多数 OLTP 系统。Aria 更像 MyISAM 的加强版，适合临时表、读多写少或不需要完整事务的场景；ColumnStore 面向分析查询；Spider 用来做分片和跨节点访问；MyRocks 适合写入密集、压缩率敏感的业务。追问为什么多数业务表建议用 InnoDB？InnoDB 的优势不只是事务，还包括崩溃恢复、MVCC、行级锁和成熟生态。订单、账户、库存这类需要一致性的表，不应为了读性能换成非事务引擎。Aria 和 MyISAM 有什么区别？MyISAM 读性能不错，但表级锁明显，不支持事务，崩溃恢复弱。Aria 是 MariaDB 对这类场景的改进选择，但仍不能替代 InnoDB 做核心交易表。ColumnStore 适合放业务明细表吗？不太适合。ColumnStore 优势是列式压缩和批量分析，适合报表和历史数据查询；频繁按主键更新、单行查询很多时会难受。更换存储引擎有什么坑？ALTER TABLE 切引擎可能锁表、耗时长，还可能遇到索引长度、外键或数据类型兼容问题。大表建议在线变更或分批迁移。写段 SQLSHOW ENGINES;CREATE TABLE event_log (id BIGINT PRIMARY KEY, created_at DATETIME, payload TEXT) ENGINE=InnoDB;

MariaDB 主从复制的核心是：主库写 binlog，从库通过 IO 线程拉取日志，再由 SQL 线程重放。最基础的是异步复制，性能好、延迟低，但主库宕机时可能丢最后几笔事务；半同步复制会等至少一个从库确认收到日志，可靠性更好，但写入延迟会上升；GTID 复制用全局事务 ID 标记事务，主从切换和故障恢复更稳。追问最小可用的主从复制怎么配置？主库要开启 serverid、logbin 和 ROW 格式 binlog，从库设置不同 server_id，并通过 CHANGE MASTER TO 指向主库。脚本要注意版本差异，新版本会逐步转向 replica 相关命令。异步、半同步和 GTID 有什么区别？异步最快但可能丢数据；半同步至少确认日志到一个从库，适合更重视数据安全的业务；GTID 是事务定位方式，让补复制、换主库更清楚。复制延迟一般从哪里排查？先看 SecondsBehindMaster、RelayLogFile、ExecMasterLog_Pos，再结合慢 SQL、从库 IO、磁盘写入和大事务判断。主从切换最容易出什么问题？从库还没追平就提升为主库，会导致新主缺数据；应用仍写旧主，会形成双写。切换前要确认 relay log 执行完和应用连接串更新完成。写段 SQLCHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;START SLAVE;SHOW SLAVE STATUS\G

MariaDB 备份不要只理解成把数据导出一份，真正要设计的是恢复能力。小库、低频变更、临时迁移，用 mysqldump 足够；线上核心库、数据量较大或恢复时间敏感，优先用 Mariabackup 做物理备份，再配合 binlog 做时间点恢复。备份策略一般按 RPO 和 RTO 倒推：能接受丢 5 分钟数据，就至少保留连续 binlog；要求 30 分钟内恢复，就不能只靠几十 GB 的 SQL 文件慢慢导入。追问mysqldump 和 Mariabackup 怎么选？mysqldump 是逻辑备份，优点是可读、可跨版本、适合单库单表恢复，缺点是大库导出和导入都慢。Mariabackup 是物理备份，恢复速度更接近文件拷贝，适合生产全量备份。如何恢复到指定时间点？常见做法是每天一次全量备份，持续保留 binlog，并记录全量备份完成时的 binlog 文件和 position。恢复时先还原全量，再用 mysqlbinlog 回放到指定时间点。备份脚本最容易踩什么坑？第一是只备份不校验，事故时才发现压缩包损坏。第二是把密码写在脚本里且权限过宽，建议用专门备份账号和最小权限。恢复前后要检查什么？恢复前确认目标目录为空、磁盘空间足够、服务已停止。恢复后要做表检查、核心 SQL 抽样和业务只读验证。写段命令mariabackup --backup --target-dir=/backup/full --user=backup --password=xxxmariabackup --prepare --target-dir=/backup/fullmysqlbinlog --stop-datetime="2026-05-30 10:18:00" mysql-bin.000123 | mysql -u root -p

MariaDB 性能调优不要一上来就改几十个参数。更可靠的顺序是：先确认慢在哪里，再看执行计划和索引，最后才调整 InnoDB、连接数、临时表、排序缓冲等配置。参数调优像放大器，SQL 和索引方向对了，它能放大性能；方向错了，它只会把问题藏得更深。追问慢查询应该怎么打开和分析？开启 slow_query_log，把 long_query_time 设置成符合业务的阈值。再按出现频率、扫描行数、总耗时排序，不要只盯单次最慢 SQL。最关键的参数是哪个？InnoDB 场景先看 innodb_buffer_pool_size，因为它影响数据页和索引页缓存命中率。专用数据库常按内存 60%-80% 估算，但要留空间给系统和连接线程。索引优化有什么取舍？高频 WHERE、JOIN、ORDER BY 列适合联合索引，但字段不是越多越好。索引会提升读，也会拖慢写入、占用磁盘。max_connections 越大越好吗？不是。它只允许更多连接进来，不代表数据库能同时跑更多重查询。连接过多会放大线程、内存和锁竞争。sortbuffersize 和 joinbuffersize 能随便调大吗？它们通常是会话级参数，并发一高总内存会放大。只有确认瓶颈并估算过峰值连接数后，才适合小步调整。写段配置slow_query_log=1long_query_time=1innodb_buffer_pool_size=8GEXPLAIN SELECT * FROM orders WHERE user_id=1001 ORDER BY created_at DESC;CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);

MariaDB 安全配置不能只理解成“把 root 密码改复杂一点”。更稳妥的做法是从账号权限、网络入口、传输加密、文件导入导出、审计日志和备份存放几个层面一起收紧。很多事故不是数据库漏洞导致的，而是测试账号没删、远程访问开太大、备份文件裸放。追问最小权限应该怎么落地？应用不要连 root，也不要授予 ALL PRIVILEGES。按业务库创建专用账号，只授予需要的 SELECT、INSERT、UPDATE、DELETE 等权限。远程访问应该怎么限制？bind-address 不要直接监听公网地址，账号 host 也不要写成 %。需要临时排障时可以开白名单，但结束后要及时移除。SSL/TLS 一定要开启吗？跨主机连接建议开启 require-secure-transport，避免账号密码和查询内容明文暴露。上线前要确认客户端驱动和证书配置支持。哪些文件相关配置容易被忽略？local_infile 建议关闭，secure_file_priv 应限制导入导出目录。备份文件要加密并放在受控目录。审计和日常运维要看什么？关注失败登录、权限变更、异常来源 IP、大批量导出和高危 DDL。日志要轮转，否则磁盘打满也是事故。写段配置CREATE USER 'app_user'@'10.%' IDENTIFIED BY 'strong_password';GRANT SELECT, INSERT, UPDATE ON app_db.* TO 'app_user'@'10.%';bind-address=10.0.0.5local_infile=0require-secure-transport=ON

MariaDB 分区表适合处理持续增长、访问模式明确的大表，比如日志、订单、流水。它不是把业务拆成多张表，而是在一张逻辑表下面按规则拆出多个物理分区；查询仍写同一张表名，优化器在条件命中分区键时可以做分区裁剪。分区能降低历史数据维护成本，也能减少部分扫描范围，但不能替代索引。追问MariaDB 分区表有哪些类型？常见类型有 RANGE、LIST、HASH 和 KEY。RANGE 适合按时间、ID 区间切分；LIST 适合地区、业务状态；HASH/KEY 主要用来均匀打散。RANGE、LIST、HASH、KEY 应该怎么选？查询经常带 created_at、biz_date 时优先 RANGE；固定枚举隔离用 LIST；没有明显范围条件但要拆散数据时考虑 HASH/KEY。创建分区表最容易踩什么坑？主键和唯一键通常必须包含分区键，否则可能建表失败或唯一性语义不符合预期。分区键不出现在查询条件里，收益也会很有限。历史分区怎么维护？RANGE 分区通常提前创建未来分区。删除历史数据时，DROP PARTITION 比大批量 DELETE 更快，但它是物理删除，归档前要先备份。怎么确认查询真的用到了分区？用 EXPLAIN PARTITIONS 看 partitions 字段，确认只访问目标分区，而不是全分区扫描。写段 SQLCREATE TABLE orders (id BIGINT, created_at DATE, PRIMARY KEY(id, created_at))PARTITION BY RANGE (TO_DAYS(created_at)) ( PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')), PARTITION pmax VALUES LESS THAN MAXVALUE);

Expo 是建立在 React Native 之上的框架和工具链，它把创建项目、真机预览、常用原生能力、路由、云端构建、商店提交和 OTA 更新放到一套工作流里。它适合快速验证产品、跨平台业务 App、前端团队主导的移动端项目，以及希望少碰 Xcode、Gradle、证书和原生桥接的团队。追问Expo 和 React Native 是什么关系？React Native 是底层跨平台运行框架，负责把 React 组件渲染成原生 UI；Expo 是围绕 React Native 的 SDK、CLI、路由和云服务。Expo Go、Development Build、EAS 分别做什么？Expo Go 适合快速预览通用能力；Development Build 是带有你自己原生配置的调试包；EAS 负责云端构建、提交商店和发布更新。哪些项目特别适合用 Expo？内容型 App、工具型 App、内部系统、轻量电商、社区产品、MVP 验证都很适合，因为它们更看重交付速度和跨平台一致性。什么场景不适合只依赖 Expo Go？涉及自定义原生模块、厂商 SDK、推送、深链、后台任务、权限文案或原生启动页时，应尽早切到 development build。Expo 的主要取舍是什么？收益是上手快、常用能力齐全、构建发布链路顺；代价是要遵守 Expo 的版本节奏和配置方式。写段命令npx create-expo-app my-appnpx expo startnpx expo run:ios

Expo 常用 API 是 Expo SDK 对原生能力的封装，常见场景包括相机、定位、通知、文件系统、媒体库、传感器、安全存储和剪贴板。它的好处是用 JavaScript/TypeScript 调 iOS、Android 能力，少写原生桥接；安全使用的重点是权限、平台差异、开发构建方式和失败兜底是否处理完整。追问Expo 常用 API 可以分成哪些类型？设备能力类包括 Camera、Location、Notifications、Sensors；系统能力类包括 FileSystem、SecureStore、Clipboard；媒体类包括 ImagePicker、Audio、Video。为什么权限明明申请了还是拿不到？很多权限既要运行时申请，也要在 app.json 或原生配置里声明用途文案。iOS 用户拒绝后再次请求不一定弹窗，Android 不同版本也有差异。Expo API 和自定义原生模块怎么取舍？常规能力优先用 Expo SDK；需要厂商支付、蓝牙深度能力、特殊后台服务时，要考虑 development build、config plugin 或原生模块。Expo Go 能不能验证所有 API？不能。Expo Go 适合预览通用能力，但不能包含你的自定义原生配置，也不适合验证真实推送证书、深链、后台任务。实战里权限请求应该放在哪里？不要每次渲染都请求权限，也不要一进 App 就弹所有权限。更稳的是在用户触发相机、定位、上传图片等动作时再申请。写段代码const { status } = await Location.requestForegroundPermissionsAsync();if (status === 'granted') await Location.getCurrentPositionAsync({});