计算机网络面试复习笔记

一份入门友好且面向面试的计算机网络笔记，系统覆盖通信模型、协议、网络层、TCP/UDP、WebSocket/WebRTC 及常见面试题。详细对比和要点如下：

通信模型
客户端-服务器：集中式架构，所有请求经服务器处理，如 Google、Amazon。
P2P：设备直接通信，无中心服务器，如 WebRTC、Torrent。

协议速览
HTTP：请求-响应、无状态、运行于 TCP。
FTP：文件传输，使用控制连接和数据连接两条通道。
SMTP：发送邮件，使用 TCP。
IMAP：读取和同步邮件，邮件保留在服务器。
WebSocket：全双工、持久连接，但仍是客户端-服务器，非 P2P。
WebRTC：点对点通信，主要用 UDP，支持音视频和数据通道。

网络层要点
应用层：HTTP/FTP/SMTP/IMAP/WebSocket
传输层：TCP/UDP（TCP 可靠有序，UDP 快速尽力交付）
网络层：IP 寻址与路由

TCP vs UDP
TCP：面向连接，有 ACK 和重传，适合文件、银行、HTTP。
UDP：无连接，无确认，速度快，适合直播、游戏、视频通话。

重要面试问答
- FTP 用两条连接：一条命令，一条数据。
- 视频通话用 UDP：速度优先，丢帧可接受。
- WebSocket 不是 P2P，是客户端-服务器。
- SMTP 发邮件，IMAP 读邮件。

整份笔记对常见协议、层模型和面试题做了清晰梳理，适合快速复习和面试准备。

#开发者 #工具 #计算机网络 #网络协议 #TCP #UDP #WebSocket #WebRTC #面试
@DevToolboxHub

AWS 推出基于 VS Code 的 AI IDE Kiro，聚焦规格驱动开发

Kiro 是 AWS 基于开源 VS Code（Code OSS）构建的集成开发环境，内置专为规格驱动（spec-driven）开发优化的 AI 工具。它改变了传统的“先写代码再重构”流程，引导开发者从需求定义、技术设计到任务拆解，逐步完成实现。

Kiro 内置多个智能代理：Spec 代理负责规划阶段的特性需求、技术设计与任务列表；Plan 代理可分析代码库并协调工作流；Bug Fix 代理实时调试并修正错误。用户通过 AGENTS.md 文件配置项目核心指令与约束。

Kiro 的规格工作流（Kiro specs）遵循“需求 → 设计 → 任务”三步法，文件自动保存在项目根目录的 .kiro/ 隐藏文件夹中：

Requirements.md：根据用户指令生成用户故事与约束清单，支持提问细化。
Design.md：基于需求生成技术蓝图，包括数据模型、API 契约、组件图、文件结构及 TypeScript 接口等。
Tasks.md：将设计转为依赖感知的任务检查表，可逐条、分组或全量执行，UI 实时显示进度。

此外 Kiro 还提供 Autopilot（自动/监督模式）、Steering（按上下文定义规则）、Slash commands（自定义斜杠命令执行指令）、Checkpoints（对话检查点，可一键回退）以及自定义 Agent 等能力。

整体使用下来，Kiro 更像一个有思考能力的协作伙伴，而非简单聊天机器人；它帮助开发者更有条理地从规划阶段进入编码，适合追求结构化 AI 辅助的开发团队。

#开发者 #工具 #Kiro #AWS #AIAssistant #SpecDriven #VSCode #IDE #CodeOSS
@DevToolboxHub

免费GitHub Action填补付费代码扫描空白

2026年7月14日，GitHub在PR上推出AI安全检测，但明确仅限GitHub Code Security（即GitHub Advanced Security）付费客户。新支持的生态系统包括Shell/Bash、Dockerfiles、Terraform、PHP——恰恰是CodeQL免费版不分析的类型。对于大量使用部署脚本、Dockerfile和Terraform的基础设施仓库，免费扫描等于零覆盖。

开发者Booyaka101推出了免费Action「ghas-free-pack」，利用成熟的开源扫描工具填补这一空缺，并将结果统一成SARIF格式，直接上传到Code Scanning并生成PR评论。

工具工作原理
在workflow中引用：Booyaka101/ghas-free-pack@v1，并授予security-events: write和pull-requests: write权限。它会自动对.sh/.bash运行ShellCheck，对Dockerfile*运行Hadolint，对.tf运行tfsec，对.php运行PHPStan（需手动启用）。所有发现被合并为一个SARIF 2.1.0文档，上传后与CodeQL的显示效果完全一致，同样出现在Security标签页中。

实际捕获示例（来自测试夹具）
- SC2163：export $INPUT导出的是变量名而非值，典型的shell静默bug
- DL3002：最后的USER是root，容器以特权运行
- aws-ec2-no-public-ingress-sgr：CRITICAL级别安全组允许0.0.0.0/0入站
- PHPStan level 5：参数类型错误和未定义变量

使用限制
这是确定性基于规则的扫描器，不复制GitHub的LLM分析。PHPStan需手动启用（enable-phpstan: true），避免默认噪音。由于是Docker action，仅支持Linux runner，首次运行需拉取镜像。SARIF上传需要security-events: write，PR评论需要pull-requests: write，缺失时仍会写job summary但无法发布。

验证可靠性
仓库附带本地测试脚本test/run-local.ps1，构建镜像后对测试夹具运行，断言17项验收标准，包括合并后SARIF通过ajv验证（需使用json.schemastore.org提供的schema）、PR评论包含预期规则、重复运行会PATCH已有评论而非重复发布。MIT许可，可放心使用。

免费工具为那些被挡在付费墙之外的基础设施仓库提供了社区驱动的安全扫描替代方案。

GitHub

#开发者 #工具 #GitHub #CodeScanning #GHAS #ShellCheck #Hadolint #tfsec #PHPStan #SARIF #DevOps
@DevToolboxHub

仅7家大公司招聘页可爬，如何一次检测

测试了42家大型雇主的招聘页面，仅7家可直接爬取。多数企业使用Taleo、Oracle等企业级ATS，不提供公开API。下面介绍如何用一个请求快速判断。

现代ATS（Greenhouse、Lever、Ashby、SmartRecruiters）提供开放API，无需认证。企业级ATS（Taleo、Oracle、Phenom、iCIMS）则依赖会话与JavaScript，无法直接抓取。通过检查招聘页HTML的正则匹配，即可识别ATS类型。
检测ATS的Python代码：import requests, re；SIGNATURES字典包含Greenhouse、Lever、Ashby、SmartRecruiters、Workday、Taleo、Oracle、Phenom、iCIMS的正则；函数detect(careers_url)发送请求并匹配，返回ATS类型。若返回Taleo等，直接放弃。
识别后调用API：Greenhouse可用GET https://boards-api.greenhouse.io/v1/boards/{slug}/jobs，Lever类似。注意Workday的limit不能超过20。
不猜slug，从真实URL读取。作者提供了一个免费的开源爬虫工具，自动检测ATS并归一化数据。

该方法可节省大量试错时间。对所有想爬招聘数据的开发者而言，先检测ATS再动手，事半功倍。

#开发者 #工具 #爬虫 #ATS #Greenhouse #Lever #JobScraping
@DevToolboxHub

双语爬虫数据陷阱：阿拉伯语与英语

爬虫教程通常只假设单语言场景。当面对阿拉伯语/英语双语市场时，会遇到一种永不抛异常的 bug：请求成功、HTML 解析正确，但每个目标字段都为空。以下是构建双语职位数据集时积累的经验。

一个字段全空的典型场景：抓取职位页的「资历级别」和「雇佣类型」，测试正常，生产环境却返回 null。状态码 200，HTML 有效。原因是链接指向了区域子域名（如 ae.example.com），返回阿拉伯语页面，而选择器匹配的是英文标签「Seniority level」「Employment type」，页面显示为「المستوى الوظيفي」和「نوع التوظيف」。修复只需在抓取前将域名规约为主域名：re.sub(r"https://[a-z]{2}\.example\.com/", "https://www.example.com/", url)。通用教训：如果一个字段在所有记录中都为空，先怀疑地区语言问题，再怀疑选择器本身。防御措施：解析后断言关键字段已填充，否则抛异常——一个会崩溃的爬虫比一个默默返回空值的爬虫好得多。

数字陷阱：阿拉伯页面常使用东阿拉伯数字（如 ٢٠٠ 表示 200）。Python 的 int("٢٠٠") 能正确返回 200，"٢٠٠".isdigit() 为 True，re.findall(r"\d+", text) 能匹配到，因为 \d 默认支持 Unicode。但大多数人习惯写 [0-9]+，这在阿拉伯数字页面上会永远返回空列表，让你误以为字段缺失。如果希望输出始终为 ASCII 数字，可以用 str.maketrans 翻译：ARABIC_DIGITS = str.maketrans("٠١٢٣٤٥٦٧٨٩", "0123456789")，再 int(re.sub(r"\D", "", text.translate(ARABIC_DIGITS)))。

关键词匹配：子串匹配在双语数据集中容易出错。例如 "coo" in title 会匹配到「Coordinator」，把项目协调员误判为首席运营官；"partner" in title 会匹配到「Partner Onboarding Specialist」，把入职专员提升为合作伙伴。解决方案：始终使用单词边界正则 re.search(r"\bcoo\b", title)。数据验证：在发布统计数字前，务必打印实际行。示例中，某市场 18% 的职位被标为「高管级」，打印后发现一半是协调员和入职专员，真实比例仅 16%。

机器翻译与编码：为双语数据集添加阿拉伯语标签时，始终保留原始字段（如 title 和 titleArabic 并存），只将翻译用于显示，所有连接、去重和过滤应在源语言字段上进行。编码方面，在所有读写边界显式设置 UTF-8：sys.stdout.reconfigure(encoding="utf-8")，Path(p).read_text(encoding="utf-8")。注意 UTF-8 BOM 可能导致部分 JSON 解析器报错，先检查 BOM 再检查语法。

以上经验来自维护区域招聘网站的爬虫（输出中英文标签），全部踩坑记录在作者的 Apify 页面。

#开发者 #工具 #爬虫 #Python #阿拉伯语 #双语数据 #Unicode #正则表达式 #数据清洗 #工程效率
@DevToolboxHub

数字化失败案例：政策与反馈循环

一位前 NHS 员工在被迫离职后，目睹了团队引入的“新系统”——把原本纸质或类 Excel 的流程搬到屏幕上，但问题依然存在：重复填写、信息重叠、无人应答。作者从工程师视角拆解了这个失败模式，指出其本质是工程中常见的经典错误：把坏流程数字化，得到数字化的坏流程。

文章从几个层面展开：政策即规格说明，软件即实现。当政策要求“提供个性化支持”而软件只提供一个硬编码流程时，实现就与规格矛盾，就像 bug 一样自然产生。系统本身是不可靠的第三方依赖——无文档、无负责人、bus factor 为零，甚至是从美国未经审查引入英国的。可及性不是 UI 问题，而是架构问题：底层模型假设所有人走同一条路径，再漂亮的界面也无法帮助那条路径之外的人。反馈环路被切断：诚实报告问题的人被惩罚，issue tracker 静默，从外部看以为系统稳定，实际上是传感器被关闭了。开源的潜力巨大，但必须与政策同步进化——仅开源实现而不改变反馈文化，只是把故障公之于众。

文章最终提出：真正的问题不是“如何数字化现有流程”，而是“如何构建一个从使用者那里持续学习的系统”。核心是把决策过程本身也变成可观测的，让反馈回路真正闭环。这与技术栈无关——Python、Java 还是纸张，底层价值观一致：透明、问责、共享责任。一个只交付服务的系统是盲目运行的，而一个能学习的系统才值得建造。

#开发者 #工具 #NHS #UK #开源 #反馈循环 #系统架构 #政策 #可观测性
@DevToolboxHub

6个AI网关横向对比：路由、治理、缓存与可观测性

AI网关是位于应用代码与模型提供商之间的单一控制面。没有它，每个服务各自处理提供商密钥、重试、速率限制、缓存和日志；有了它，所有请求穿过同一端点，获得一致的访问规则、配额、成本核算和审计记录。

评估网关应关注：是否整合了多提供商接入、能否限制开销是否通过缓存去重、是否保留持久审计日志、能否在延迟/成本/输出质量变化时了解生产状况。

本次对比覆盖六个产品，分为两大类：基础设施优先型（在现有API管理、K8s或边缘平台上扩展AI能力）和LLM原生型（从模型接入、流量监控入手）。选型取决于你的真实约束是基础设施控制、提供商路由，还是将生产流量与质量度量挂钩。

1. Braintrust Gateway
最适合想将模型路由与追踪/评估整合在同一系统中的团队。提供单一API路由至OpenAI、Anthropic、Google、AWS、Azure、Mistral等。通过指向gateway.braintrust.dev即可接入。关键特性：网关流量默认进入可观测与评估层，无需额外插桩即可追踪输入、输出、延迟和成本；这些跨度可评分、注释、加入数据集、用于CI检查。缓存支持AES-GCM加密并按用户隔离。免费Beta中，Pro $249/月。

2. Portkey
面向需要托管网关捆绑治理、护栏、提示管理与合规控制的企业团队。通用API包含路由、回退、负载均衡、重试、虚拟密钥、日志、追踪、元数据、过滤器和告警。支持确定性护栏与基于LLM的护栏。Free层10K日志请求，付费$49/月起，企业版含SSO、细粒度预算等。

3. LiteLLM
适合有DevOps能力的团队，运行自托管开源网关。Python SDK及Proxy Server支持100+提供商，提供虚拟密钥、预算、团队、负载均衡、RPM/TPM限制、护栏及日志集成（Braintrust、Langfuse等）。免费开源，企业版含SSO和审计日志。

4. Kong AI Gateway
适合已运行Kong的企业，将AI控制能力通过插件嵌入现有API管理栈：通用LLM路由、语义缓存、MCP/A2A网关、RAG注入、护栏等。需部署完整API管理平台，部分插件需付费，无原生评估工作流。30天免费试用。

5. SUSE AI Universal Proxy
面向K8s原生企业，关注MCP服务器治理与代理。开源（Apache 2.0），提供发现、注册、身份认证、成本追踪、日志等功能。更偏向MCP治理层而非通用LLM路由器。需K8s与平台运维能力。

6. Cloudflare AI Gateway
希望边缘缓存、速率限制、使用可见性且无需运维的团队。通过Cloudflare路由AI请求，核心功能全计划免费。可观测性以指标和日志为主，结构化评估需独立系统。部分功能处于Beta或依赖其他Cloudflare订阅。

选型总结
- 基础设施治理是约束 → Kong或SUSE
- 你想拥有代理 → LiteLLM（覆盖最广、免费，但需工程能力）
- 需要治理/护栏/提示管理一体化 → Portkey
- 需要边缘缓存+零运维 → Cloudflare
- 需要路由直接接入评估与发布检查 → Braintrust（唯一将网关流量变为评估输入的选项）

值得注意的差距：五款工具停留在告诉你发生了什么（指标、日志、成本仪表盘），而网关本身就持有最宝贵的评估数据——真实输入、输出、延迟和成本。如果这些数据不能流入数据集、评分器与预发布检查，你仍需重建第二条管道。Braintrust是本次对比中唯一围绕闭环构建的产品，这使其成为推荐首位，而非单个网关特性。

#开发者 #工具 #AIGateway #Braintrust #Portkey #LiteLLM #Kong #SUSE #Cloudflare #LLM #可观测性
@DevToolboxHub

十年企业搜索经验，一朝开源：Viglet Turing ES

作者过去十年为企业构建搜索，最终将实践整合为一个统一平台，并以 Apache 2.0 开源：Viglet Turing ES。它的设计围绕三个关键决策，一个命令即可运行。

1. 运行在你已有的引擎之上
不替换 Solr / Elasticsearch / Lucene，而是作为上层统一查询 API。混合检索融合 BM25 与向量结果（Reciprocal Rank Fusion），可插拔重排序（LLM / cross-encoder / Cohere）。空环境可用嵌入式 Lucene，单容器运行。模型支持 OpenAI / Anthropic / Gemini / Azure 或完全本地 Ollama，断网部署时所有组件本地运行。

2. 可审计的回答，包括“无答案”
RAG 聊天流式返回内联引用，追溯到源头段落。LLM 前有相关门控过滤弱匹配，生成后可选 groundedness check 标记来源不支持的陈述。索引内无匹配时，助手给出确定的“not covered here”而非编造。这一行为在受监管组织中至关重要。

3. 基于同一索引的 Agent
搜索与 RAG 共享索引后，Agent 可操作内容而不仅仅是回答。支持工具调用、Docker 沙箱技能、MCP 服务器连接，同一个助手既能引用文档也能调用内部 API。

一条命令即可本地运行（无需账号、无遥测）：docker run -p 2700:2700 ghcr.io/openviglet/turing-ce ，控制台访问 http://localhost:2700/console（首次启动用 TURING_ADMIN_PASSWORD 环境变量设置管理员密码）。搜索和 RAG 聊天均提供 REST API，另有 TypeScript SDK（零依赖版与 React 版）。在线演示基于同一 SDK 运行在 Turing 自身文档上，安装前即可看到带引用的回答。

GitHub: github.com/openviglet/turing-ce

#开发者 #工具 #VigletTuringES #企业搜索 #RAG #开源 #Solr #Elasticsearch #Lucene #自托管
@DevToolboxHub

AWS GuardDuty 推出调查代理公测

AWS 发布 GuardDuty investigation agent 公开预览。该 AI 安全工具自动关联安全发现、90 天活动日志与资源拓扑，生成带风险评级、置信度评分和 MITRE ATT&CK 分类的结构化报告。调查可通过 AWS MCP Server 经由智能体工具链执行，将安全调查流程从数小时缩短至数分钟。预览期间每个账户每日最多执行 10 次调查。

#开发者 #工具 #AWS #GuardDuty #安全 #威胁分类 #MCP #公测 #SaaS
@DevToolboxHub

Uber零增长堆栈：解耦扩容与优化AI成本

Uber 推出的"零增长堆栈"（Zero Growth Stack）是一套可扩展基础设施方案，核心目标是将容量增长与业务需求解耦，从而在减少物理硬件投入的同时保持服务弹性伸缩。方案的关键技术之一是垃圾回收（GC）优化，以提升运行时效率。另一方面，Uber 将生成式 AI 集成到开发流程中，提升开发者生产力，并同步引入 AI 成本管理机制，确保经济可持续性。

#开发者 #工具 #Uber #零增长堆栈 #垃圾回收 #生成式AI #基础设施 #AI成本管理
@DevToolboxHub

Remix 3 Beta 弃用 React，转向 Web 标准全栈框架

Remix 3 beta 预览版发布，这是一次彻底重写，从 React 转向基于 Web 平台原语的全栈框架。它由 React Router 团队打造，不再依赖 React，而是使用 fork 的 Preact 作为前端。

新框架将路由、请求处理器和 UI 组件整合为单一结构，强调服务端拥有请求生命周期的控制权。路由和渲染从“中心栈”变为完整全栈。

从 Remix 2 迁移并非直接升级，现有应用需要修改才能适配。

#开发者 #工具 #Remix3 #全栈 #React #Preact #服务端
@DevToolboxHub

ARET：将Windows x86二进制转为原生Linux ELF

ARET（Automatic Reverse Engineering Toolkit）是一个用 Rust 编写的开源项目。输入一个 Windows .exe，它返回一个可以直接在 CPU 上运行的原生 Linux ELF —— 不需要 Wine、QEMU 或任何运行时虚拟化。

ARET 的工作方式是将机器码通过类型化 SSA IR 翻译为 C 语言，再用原生 shim 层重新实现系统调用，最后编译为普通原生二进制。输出可以是 ELF 或 WebAssembly 模块。

架构流程：Windows PE → x86 解码器 → 类型化 SSA IR → C 后端 / WASM 后端 → ELF 二进制 / WebAssembly + 原生 Win32/CRT HLE 层。

HLE 层不模拟 Windows 内核或 CPU，而是为程序所需的 Win32/CRT API 提供原生 C 实现（如 kernel32、msvcrt、user32）。文件路径做 Windows→POSIX 转换，线程通过 ucontext 协作式纤程实现，GUI（开发中）使用 SDL2 和 FreeType 渲染原生控件。

关键设计：共享栈模型——不做函数签名恢复，直接保留显式机器栈状态，通过传值方式传递栈指针 esp，确保 cdecl/stdcall/regparm 等调用约定下参数安全传递。

正确性原则：所有机制要么通过独立参考（Unicorn 指令、Wine API、Z3 SMT 重写）验证，要么在无法建模时明确中止，避免静默错误。

同一 IR 支持：透明编译到 C/LLVM/WASM、反编译为可读伪 C、控制流图分析、墙检测（静态发现未建模指令和缺失导入）。在 27 MB 游戏二进制上恢复了约 43k 个函数。

验证方式：差分测试，仓库包含 21 个二进制回归测试集，以 Wine 为参考。已验证 Lua 5.4.7、sqlite3.exe、NASM 2.16.01、busybox-w32、strings.exe 等，输出与 Wine 字节一致。

当前局限：仅支持 x86 32 位，64 位尚未实现；GUI 栈不完整；无 DirectX 支持；无内核驱动；依赖未文档化 Windows 内部的程序可能触发“中止”墙。

GitHub

#开发者 #工具 #ARET #Rust #逆向工程 #二进制翻译 #Linux #Windows #静态翻译
@DevToolboxHub

Grafana Assistant 扩展至30余数据源

Grafana Labs 近日升级 Grafana Assistant，使其 AI 驱动的可观测性助手能通过自然语言查询和关联超过30种不同数据源的数据。官方称，这标志着向“统一可观测性”迈出关键一步。

运维人员、开发者及站点可靠性工程师（SRE）可直接用自然语言调查事件、生成查询，无需手动切换数据源。该更新降低了多数据源关联分析的门槛，有助于更快定位问题。

#开发者 #工具 #Grafana #可观测性 #AI #GrafanaAssistant #数据源
@DevToolboxHub

当同一批 AI 编码工具，被两种语言评价

掘金上搜「热门 AI」，看到的工具榜单几乎重叠，但评价语言却完全不同。一种是等级制（S、A、B、D），另一种是采购语言（等保三级认证、国密SM4加密）。同一批产品，两个世界。

等级制榜单用 Tier 字母压缩印象：Cursor 和 Claude Code 在 S 列，Codex 在 A 列（"起步较晚"），Lovable 和 Bolt 在 B 列，Windsurf 因"创始人跑路"掉到 D。读下来像英译中的英文 tier list。
采购制榜单则用另一套标尺：CodeBuddy 得 9.7/10，凭据是"等保三级认证、国密SM4加密、中文代码生成接受率 87%、Figma 转换准确率 99.9%"。FlowDesign 7.3/10（"功能相对单一"），CodePulse 7.4/10（"补全准确率 92%"）。读起来像招标文档。
两种框架都真实。等级制回答的是"模型好不好"，采购制回答的是"单位能不能买"。但只读其中一种都有盲区：只看等级，可能原型通过了、法务不让上线；只看采购，可能合规了、团队用不起来。
最近三四个月掘金明显偏向采购侧语言，也许因为国内企业买家更认具体合规条款。一条实用建议：签单前，两类评测各读一篇。若它们推荐了不同工具，就该问第三个问题——这工具在你自己的真实仓库上表现如何。

#开发者 #工具 #AI编码工具 #Cursor #ClaudeCode #CodeBuddy #掘金 #等保 #国密
@DevToolboxHub

SpendGuard 阻止 Agent 烧光预算

AI Agent 循环调用、重复发送相同提示，等到月底看账单才惊觉费用失控。这个开源代理服务挡在 Agent 前方，设置预算上限并能在运行中切断调用；检测到重复提示时自动打断循环；拦截已被你禁止的工具调用（如 delete_*）后再交给代码。无需注册，本地运行。

GitHub

#开发者 #工具 #SpendGuard #AIagent #开源 #预算控制
@DevToolboxHub

Android 16 目标 API 36 截止 2026 年 8 月 31 日

Google Play 公布：2026 年 8 月 31 日起，所有新应用及应用更新必须 target Android 16（API level 36）。在维护 React Native 项目的开发者需同步调整 compileSdk 与 targetSdk，并适配平台行为变化。迁移步骤相对直接，但几个关键改动值得注意。

迁移步骤概要（React Native 项目）
安装 Android SDK Platform 36（Android Studio → SDK Manager）
更新 Gradle：compileSdk = 36，targetSdk = 36（无需改 minSdk）
更新 Android Gradle Plugin（例如 8.6.1）及 Gradle Wrapper（如 8.13）
验证 Kotlin 版本（推荐 2.0.21）
清理重建：cd android && ./gradlew clean && npx react-native run-android

检查清单（上传前确认）
安装 SDK 36 → 更新 compileSdk → 更新 targetSdk → 升级 AGP → 升级 Gradle → 验证 Kotlin → 更新第三方原生库 → 清理重建 → 在 Android 16 设备/模拟器测试 → 验证 edge-to-edge 布局 → 生成 release AAB → 上传 Play Console 检查警告

Android 16 重要行为变化
Edge-to-Edge 强制：应用内容会延伸到状态栏和导航栏下方，需用 SafeArea、react-native-safe-area-context 处理
大屏幕支持：宽度 ≥600dp 的设备（平板、折叠屏、Chromebook）将忽略方向锁定、宽高比限制，应用需适配不同窗口尺寸
后台调度变化：scheduleAtFixedRate() 在错过多次执行后只触发一次，减少无用后台工作
本地网络保护：与智能家居、打印机、IoT 设备等通信的应用建议提前测试，未来版本可能要求显式权限
照片选择器改进：如果用户仅授权“选定照片”，Android 16 会自动预选本应用创建的媒体
后台任务：JobScheduler 配额调整，使用 WorkManager/JobScheduler 的应用需验证任务执行

常见升级后问题
构建失败：一般因 AGP、Gradle、Kotlin、AndroidX 或第三方库过时引起
UI 问题：强制 edge-to-edge 导致内容被状态栏/导航栏遮挡，通常通过正确处理 WindowInsets 和 SafeArea 解决
推荐 React Native 版本：0.72 及以下建议升级，0.73–0.78 需充分测试，0.79+ 对新 SDK 支持更好

尽早迁移，避免 Play Console 提交问题，同时让应用获得最新的安全、隐私和性能改进。

#开发者 #工具 #Android16 #ReactNative #GooglePlay #API36 #迁移
@DevToolboxHub