Web

调用方需要的不只是三位数字，还要知道是否收到 HTTP 响应、正文是否完整到达，以及应用结果是否满足预期操作。这是三个不同的问题。二百响应可以按既定契约携带应用层失败，也可能在响应头之后发生传输中断；没有收到响应之前就连接失败，则根本没有 HTTP 状态。诊断和指标应保留这些区别，不能把它们压成一个过于简单的成功标志。 按实际取得的证据分类 HTTP 错误响应仍然是一份响应，其中可能包含有用的表示、认证挑战、请求标识或 Retry-After 字段。有些客户端库会为四开头和五开头状态抛出异常，但仍允许读取这些信息。处理时应先捕获具体 HTTP 异常，再处理更宽泛的传输异常；否则，一个带明确限流提示的四二九，就可能被归成和连接失败完全相同的通用网络错误，丢失下一步判断依据。 HTTP 交换成功也可能只代表业务信封成功传递。例如批处理或 RPC 契约可以返回二百，同时在正文里说明某个子操作失败。应读取文档定义的结构，而不是默认这种响应里的业务全部成功，也不能断言所有此类接口都违反 HTTP。监控需要验证自己承诺监控的结果；如果业务契约要求检查正文，那么只读状态码就没有完成相应检查。 坏掉的样子 在收到响应头时记录状态，可能掩盖随后出现的正文截断。Content-Length、流结束、解压与解析，都影响最后是否得到可用表示。应把已经收到的状态与未完成的传输分别报告，不能因为状态指标已经计入二百，就把只有半份内容的响应视为应用成功。收到响应头，是比完整收到并理解业务结果更早的一个验证点。 是否重试也不能只看第一位数字。四二九表示请求受到限流，可以附带 Retry-After；五零三也可能建议等待。该字段可以使用延迟秒数或 HTTP 日期，但两种形式都没有保证服务器到时一定恢复。客户端应结合服务器提示、有界重试策略、退避和操作语义，避免一遇到错误就立即重放。等待提示不是无限重试的授权，也不是恢复成功的证据。 非幂等请求的响应丢失，可能让业务效果处于未知状态：客户端失去联系之前，服务器也许已经提交。没有合适的幂等契约就重复操作，可能产生重复工作。另一方面，有些四开头错误会随着身份、状态或限流条件改变而变得可恢复。按照整个类别制定“总是重试”或“绝不重试”，会抹掉真正需要用于决策的信息，而不是简化正确的处理逻辑。 状态码本身也不能说明究竟是哪一个组件生成了响应。源站、网关和中间层都可能返回错误，归因时应结合请求标识与相应日志。curl 的 000 一类诊断值，不是注册的 HTTP 响应状态，通常表示没有取得可用的 HTTP 状态。把它当成某种服务器错误，会把连接阶段的问题错误地归到已经收到响应之后的处理阶段。 快速验证 将脚本保存为 status-client.py 并执行 python3 status-client.py。临时回环服务器提供五种响应情况；客户端使用真正的 urllib 响应对象和异常机制，并为实验关闭代理路由，不进行自动业务重试。另一个已经绑定但没有开始监听的回环端口用于产生拒绝连接，不需要访问外部主机，也不会依赖某个远端服务恰好离线。 from http.client import IncompleteRead from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer from threading import Thread from urllib.error import HTTPError, URLError from urllib.request import ProxyHandler, build_opener import json import socket class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path == '/application-error': status, data, retry = 200, b'{"ok":false,"error":"demo"}', None elif self.path == '/busy': status, data, retry = 503, b'{"error":"unavailable"}', '3' elif self.path == '/limit': status, data, retry = 429, b'{"error":"limited"}', '2' else: status, data, retry = 404, b'{"error":"missing"}', None if self.path == '/truncated': self.send_response(200) self.send_header('Content-Length', '100') self.end_headers() self.wfile.write(b'partial') return self.send_response(status) self.send_header('Content-Type', 'application/json') self.send_header('Content-Length', str(len(data))) if retry: self.send_header('Retry-After', retry) self.end_headers() self.wfile.write(data) def log_message(self, *args): pass opener = build_opener(ProxyHandler({})) def inspect(url): try: try: response = opener.open(url, timeout=3) except HTTPError as error: response = error with response: result = {'http_status': response.code, 'retry_after': response.headers.get('Retry-After')} try: body = response.read() except IncompleteRead: return {**result, 'complete_body': False} return {**result, 'complete_body': True, 'payload': json.loads(body)} except URLError: return {'http_status': None, 'transport_failure': True} server = ThreadingHTTPServer(('127.0.0.1', 0), Handler) thread = Thread(target=server.serve_forever) thread.start() try: origin = f'http://127.0.0.1:{server.server_port}' results = {path: inspect(origin + path) for path in ('/application-error', '/busy', '/limit', '/missing', '/truncated')} with socket.socket() as reserved: reserved.bind(('127.0.0.1', 0)) # Bound without listen: no HTTP server on this port. results['connection-refused'] = inspect(f'http://127.0.0.1:{reserved.getsockname()[1]}/') assert results['/application-error']['http_status'] == 200 assert results['/application-error']['payload']['ok'] is False assert results['/busy']['http_status'] == 503 and results['/busy']['retry_after'] == '3' assert results['/limit']['http_status'] == 429 and results['/limit']['retry_after'] == '2' assert results['/missing']['http_status'] == 404 assert results['/truncated'] == {'http_status': 200, 'retry_after': None, 'complete_body': False} assert results['connection-refused'] == {'http_status': None, 'transport_failure': True} print(json.dumps(results)) finally: server.shutdown() thread.join() server.server_close() 应用信封返回 HTTP 二百与 ok: false。繁忙和限流端点分别返回五零三、四二九，并保留 Retry-After 的三秒和两秒文本值。缺失端点仍被记录成 HTTP 四零四，而不是传输错误。这四份正文在本实验中均完整且可解析，因而能够进一步判断其业务字段；脚本没有实际等待这些延迟，也没有宣称等待后一定成功。 ...

UTF-8 用一到四字节编码 Unicode 标量值。ASCII 字符保持熟悉的单字节表示，许多其他字符则需要更长序列。它适合文本交换，却不会让任意字节自动成为有效文本，也不会让每个字节偏移都成为字符边界。正确处理需要编码约定、符合契约的有效性检查，以及对原始字节和已经解码文本的明确区分。 坏掉的样子 文件或网络读取可以停在多字节序列中间。每块独立解码，会拒绝原本完整且有效的整个字节流；如果每块都立即替换错误，还可能破坏本应与下一块组成字符的字节。流式解码器需要保留未完成输入，等后续数据到来再处理，并在流结束时检查是否仍有残缺序列。分块边界是传输细节，不是文本天然边界。 UTF-8 的起始与续字节具有可识别模式，但这不使任意切片安全。直接截断编码后的字节串，可能把一个序列切成两半。使用另一种编码成功解码，也不能证明解释正确。Latin-1 能映射每个字节，因此把 UTF-8 误解为 Latin-1，仍会得到合法 Unicode 字符串，却可能已经成为乱码。有效字符串和正确文本不是同一结论。 编码有效性还不同于文本等价与显示宽度。一个看起来带重音的字母，可以由单个码点表示，也可以由基础字母和组合标记表示。规范化能够让选定形式便于比较，但 UTF-8 解码不会自动完成规范化。同样，字节顺序标记可能成为字符串开头的实际字符，除非选定编解码器明确消费它。不能把这些处理都笼统称为“转换编码”。 快速验证 将脚本保存为 check-utf8.py，准备 Docker 后执行 python3 check-utf8.py。固定 Python 3.11.16 容器在无网络环境下运行标准库编码与 Unicode 操作，输入都是内存中明确给出的字节和字符串。实验不迁移数据库，也不转换现有文件；断言依赖字节和码点，不要求终端能够正确绘制某个表情图形： import json,subprocess,uuid image="python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84" program=r""" import codecs,json,unicodedata text='A中🙂';encoded=text.encode('utf-8');assert len(text)==3 and len(encoded)==8 assert encoded.hex()=='41e4b8adf09f9982' and encoded.decode('utf-8')==text pieces=[encoded[:2],encoded[2:5],encoded[5:]] split_errors=0 for piece in pieces: try:piece.decode('utf-8') except UnicodeDecodeError:split_errors+=1 assert split_errors==3 decoder=codecs.getincrementaldecoder('utf-8')(errors='strict');decoded=[] for piece in pieces:decoded.append(decoder.decode(piece,final=False)) decoded.append(decoder.decode(b'',final=True));assert ''.join(decoded)==text rejected={} for label,raw in {'overlong':bytes.fromhex('c0af'),'surrogate':bytes.fromhex('eda080'), 'too_large':bytes.fromhex('f4908080'),'truncated':bytes.fromhex('e4b8')}.items(): try:raw.decode('utf-8');raise AssertionError('invalid UTF-8 accepted') except UnicodeDecodeError as error:rejected[label]=error.reason bad_tail=codecs.getincrementaldecoder('utf-8')();assert bad_tail.decode(bytes.fromhex('e4b8'),final=False)=='' try:bad_tail.decode(b'',final=True);raise AssertionError('incomplete final sequence accepted') except UnicodeDecodeError:final_rejected=True mojibake=encoded.decode('latin-1');assert mojibake!=text and mojibake.encode('latin-1')==encoded decomposed='e\u0301';composed='é';assert decomposed!=composed and unicodedata.normalize('NFC',decomposed)==composed bom=b'\xef\xbb\xbf'+encoded;assert bom.decode('utf-8').startswith('\ufeff') and bom.decode('utf-8-sig')==text replacement=bytes.fromhex('ff41').decode('utf-8',errors='replace');assert replacement=='\ufffdA' print(json.dumps({'text':text,'code_points':len(text),'bytes':len(encoded),'hex':encoded.hex(), 'chunk_hex':[x.hex() for x in pieces],'independent_chunk_failures':split_errors,'incremental_output':decoded, 'invalid_rejections':rejected,'final_incomplete_rejected':final_rejected,'latin1_code_points':[hex(ord(c)) for c in mojibake], 'normalization_lengths':[len(decomposed),len(composed)],'bom_utf8_first':hex(ord(bom.decode('utf-8')[0])), 'utf8_sig_strips_bom':bom.decode('utf-8-sig')==text,'replacement':replacement},ensure_ascii=False)) """ name='xbcatm-socket-'+uuid.uuid4().hex[:10] try: result=subprocess.run(['docker','run','--rm','-i','--name',name,'--network','none', '--memory','128m','--pids-limit','64',image,'python3','-'],input=program, capture_output=True,text=True,timeout=60) assert result.returncode==0,result.stderr print(json.dumps(json.loads(result.stdout),ensure_ascii=False,sort_keys=True)) finally: subprocess.run(['docker','rm','-f',name],capture_output=True,text=True,timeout=10) 字符串 A中🙂 在 Python 中具有三个对应码点的元素，编码后为八字节，十六进制是 41e4b8adf09f9982。ASCII 占一字节，汉字占三字节，表情占四字节；重新解码返回原文。编码字节数和这些码点数量回答不同问题，也都不能自动等同于屏幕列宽。限制字段长度前，必须先明确限制使用哪种单位。 ...

服务器名称指示 SNI 在 TLS 服务器选择握手参数和证书时，提供客户端希望访问的主机名。本文讨论的是证书认证且没有 early data 的路径，因此选择发生在普通 HTTP 字节发送之前，不是网络上任何字节都还没出现的时候。SNI 只是帮助选择，客户端仍然必须验证返回的证书身份。 同一个地址上的不同决策 客户端把 server_name 放在 ClientHello 中，托管多个名称的服务器可以据此选择证书或安全配置。TLS 1.3 在 ServerHello 之后加密证书消息，所以“选证书和传证书都在加密开始之前完成”不是准确描述。应区分先收到选择提示，和随后如何保护证书及其他握手消息。 SNI 中的 DNS 主机名不等于建立连接时使用的目标 IP，填写名称也不要求实验域名真的经过公共 DNS 解析。RFC 6066 不允许在 HostName 字段直接放入 IPv4、IPv6 字面地址，并规定 DNS 主机名比较不区分大小写。客户端直接按 IP 访问时，可以不发送 DNS SNI，转而验证对应的 IP 身份。 ...

Server-Timing 响应头允许服务端给响应附加具名测量结果，浏览器开发者工具和性能接口随后可以把这些结果与对应资源请求关联起来。当网络瀑布图只能显示等待很久，却无法说明后端是否在查询数据库、渲染页面或执行其他操作时，这类信息很有帮助。但它提供的是服务端选择上报的观测结果，并不是浏览器独立测得这些内部操作的耗时，因此仍然需要理解测量范围和产生位置。 正确的时长语法是 db;dur=42, render;dur=81，建议使用毫秒作为单位。浏览器解析数值，但无法验证发送方实际采用的单位。直接写 db=42，并不是这项协议表达时长的方式。每个指标有名称，也可以带时长和描述参数。生产环境应采用含义稳定的名称，从实际插桩中得到数值。描述可以解释测量对象，但不应包含响应本来不该披露的原始查询、身份编号或内部细节。浏览器能够展示字段，不代表所有调试内容都适合跟随响应对外发送。 让数值对应明确的时间区间 服务端的多个测量值不一定能加成浏览器看到的请求总耗时。它们可能覆盖嵌套操作、相互重叠的工作，也可能只覆盖处理路径的一部分。只有数据库时间与渲染时间的定义允许相加时，加总才有意义。网络传输、测量区间之外的排队、缓存和客户端处理，都可能解释两侧数字的差异，并不一定说明某个时钟有错误。应先弄清每个数值从哪里开始、在哪里结束。 这个响应头也不会自动生成分布式链路。它在单个响应上命名测量结果，并没有自动提供父子关系、跨服务传播或采集器存储。可以用它展示少量对请求有帮助的测量，再通过日志或链路关联获取更深的解释。当响应经过缓存和代理时，还应检查最终交付的响应头，确定这些数字由哪个组件产生。读取一个字段与证明当前源站执行了相应工作，是不同层次的证据。 坏掉的样子 跨源资源存在两个容易混淆的权限边界。CORS 允许脚本读取响应，而 Access-Control-Expose-Headers 可以让 response.headers 暴露 Server-Timing 字段。Timing-Allow-Origin 则控制相应的详细资源计时信息是否可见。安全上下文与浏览器隐私规则还可能进一步限制计时暴露。因此，脚本成功读取响应头，并不能证明 PerformanceResourceTiming.serverTiming 数组一定包含同样的数据。排查时需要分别验证，不能只用其中一个接口有值就推断另一项能力已经成立。 另一个错误，是把解析演示当成真实性能测量。服务端发送固定时长，只能证明浏览器怎样解析这个数字，不能说明处理器实际运行了那么久。同样，计时数组为空，也不能证明服务端没有做任何工作。应先核对来源授权与真实线上响应头，再检查测量代码放置的位置。公开名称与说明还要符合接收对象的范围，避免为了排障而把不该公开的后端结构随响应一起暴露出去。 快速验证 将代码保存为 server-timing.py，执行 python3 server-timing.py –serve；此前记录使用 Python 3.14.4；本轮没有重跑套接字或浏览器测试。脚本在两个不同的临时端口上启动本机回环 HTTP 服务，因此它们是不同来源，然后输出待打开的页面地址。页面会请求两份资源，把响应头内容与浏览器解析出的性能条目同时显示出来。结束后按控制键加 C 关闭两个服务；不带服务参数执行时，只检查响应头并退出，不会自动运行浏览器。 import json import sys from http.server import BaseHTTPRequestHandler, HTTPServer from threading import Event, Thread from urllib.request import Request, urlopen timing = "db;dur=42, render;dur=81" class API(BaseHTTPRequestHandler): def log_message(self, *args): pass def do_GET(self): body = b"synthetic timing fixture\n" self.send_response(200) self.send_header("Content-Type", "text/plain; charset=utf-8") self.send_header("Content-Length", str(len(body))) self.send_header("Cache-Control", "no-store") self.send_header("Access-Control-Allow-Origin", app_origin) self.send_header("Access-Control-Expose-Headers", "Server-Timing") self.send_header("Server-Timing", timing) if self.path.split("?", 1)[0] == "/allow": self.send_header("Timing-Allow-Origin", app_origin) self.end_headers() self.wfile.write(body) class App(BaseHTTPRequestHandler): def log_message(self, *args): pass def do_GET(self): body = ("""<!doctype html><meta charset="utf-8"><title>Server-Timing lab</title> <h1>Cross-origin Server-Timing</h1><pre id="result">Running...</pre> <script> const api = """ + json.dumps(api_origin) + """; async function run() { performance.clearResourceTimings(); const results = {}; for (const path of ['deny', 'allow']) { const url = api + '/' + path; const response = await fetch(url, {cache:'no-store'}); await response.text(); await new Promise(resolve => requestAnimationFrame(resolve)); const entry = performance.getEntriesByName(url).at(-1); results[path] = {header:response.headers.get('Server-Timing'), timing:entry.serverTiming.map(item => ({name:item.name, duration:item.duration}))}; } window.labResult = results; document.getElementById('result').textContent = JSON.stringify(results, null, 2); } run().catch(error => {window.labError=String(error); document.getElementById('result').textContent=String(error);}); </script>""").encode() self.send_response(200) self.send_header("Content-Type", "text/html; charset=utf-8") self.send_header("Content-Length", str(len(body))) self.end_headers() self.wfile.write(body) api = HTTPServer(("127.0.0.1", 0), API) app = HTTPServer(("127.0.0.1", 0), App) api_origin = f"http://127.0.0.1:{api.server_port}" app_origin = f"http://127.0.0.1:{app.server_port}" threads = [Thread(target=server.serve_forever, daemon=True) for server in (api, app)] for thread in threads: thread.start() try: for path in ("deny", "allow"): with urlopen(Request(api_origin + "/" + path, headers={"Origin": app_origin}), timeout=5) as response: assert response.headers["Server-Timing"] == timing assert response.headers["Access-Control-Allow-Origin"] == app_origin assert response.headers["Access-Control-Expose-Headers"] == "Server-Timing" assert response.headers.get("Timing-Allow-Origin") == (app_origin if path == "allow" else None) response.read() print(json.dumps({"app_url": app_origin, "api_url": api_origin, "wire_checks": "PASS", "durations_are_synthetic": True}), flush=True) if "--serve" in sys.argv: Event().wait() except KeyboardInterrupt: pass finally: for server in (api, app): server.shutdown() server.server_close() for thread in threads: thread.join(timeout=5) 两份响应都通过 CORS 允许页面来源，都显式暴露 Server-Timing，也都携带同样的合成数据库与渲染时长。只有 allow 路径额外提供 Timing-Allow-Origin。在此前 Chrome 152 的观察记录中，两侧脚本都读到 db;dur=42, render;dur=81，但未授权的计时数组为空，已授权数组则包含名为 db、时长四十二，以及名为 render、时长八十一的两项结果。这份浏览器证据与 Python 的线上响应头断言分别检查，避免用非浏览器客户端代替实际可见性验证。 ...

Age 是从源站生成或成功验证响应以来，已经经过多少秒的估计值，包含缓存驻留和网络传输时间。它不是对象的创建时间戳，也不是访问次数，更不只是最后一台代理在磁盘上保存副本的时长。要判断这个数字意味着什么，必须同时查看响应的新鲜度策略和实际请求上下文，不能把年龄直接等同于是否允许复用。 合并估计时不能重复计时 RFC 9111 定义了接收响应时的两种年龄估计。表观年龄用接收缓存的时钟减去 Date，如果得到负数，就按零处理。校正年龄从收到的 Age 数值出发，再加上发出请求到收到响应之间的时间。缺少 Age 时，这个输入按零参与计算，但并不意味着应当丢掉基于 Date 的另一种估计。 当缓存链满足相关 HTTP 行为要求时，RFC 允许直接使用校正年龄；更保守的计算则取表观年龄与校正年龄的较大值，再加本地驻留时间。下面的实验采用后者。把这两种估计直接相加，会重复计算互相重叠的时间；而每经过一个缓存就把 Age 清零，又会丢掉上游已经积累的历史。 请求、接收和本地驻留时间应使用一致的测量方法，Date 比较还依赖时钟同步。因此结果仍然是估计，而不是精确秒表。生产实现需要恰当处理时钟和输出整数值。下面只使用固定的整秒 UTC 时间与合法头字段，展示指定计算步骤，不构成一套完整的 HTTP 缓存实现。 新鲜度是另一个判断 当前年龄为四十五秒，寿命为六十秒时仍在新鲜期；同样的年龄放在三十秒寿命下，就已经陈旧。相等时也算陈旧，因为新鲜要求年龄严格小于寿命。不过，这个比较本身并不授权复用。请求限制、缓存键、Vary、存储规则和要求验证的指令，都可能让一份年龄很小的响应仍然不能直接返回。 对于共享缓存，s-maxage 覆盖 max-age，其数值既可能缩短，也可能延长适用寿命。stale-while-revalidate 并不是把旧响应重新变成新鲜，而是在策略与实现允许的条件下，一边验证一边有限使用陈旧副本。应把“允许服务旧内容”视为另一种状态，不要把所有宽限期都混进新鲜期的定义。 坏掉的样子 Age 很大，不自动证明发布出了问题。缓存寿命为一年的指纹资产，即使年龄很大也可能仍然新鲜。正文没有改变的表示，还可以在后来成功通过验证，只更新元数据而不替换字节。此后 Age 对应的是较新的验证历史，不一定反映这些字节最初被作者写出的时间，不能据此计算内容存在了多久。 同一 URL 的每次请求也不保证 Age 单调递增。请求可能到达不同边缘、选择不同表示、遇到条目淘汰，或经过成功的重新验证。Age 为零也可能来自刚缓存的响应；没有这个头，同样不能单独证明一定由源站直接应答。应对照匹配的请求、正文身份、验证器、Date、缓存策略和服务商诊断字段一起判断。 ...

Cookie 的主机与路径作用域，决定哪些目的地有资格收到它的名称和值。缩小这个集合有助于减少暴露，但作用域不是授权，而且 Cookie 并不采用浏览器完整的源边界。本文重点讨论 Domain 与 Path；传输方式、请求语境和浏览器策略还会增加其他限制，不能只凭一个属性就推断最终发送结果。 Domain 选择主机，不隔离端口 省略 Domain 会建立 host-only Cookie。从 app.example.com 设置的 Cookie 只匹配这个主机，不匹配 shop.example.com。加入 Domain=example.com，则允许父域与匹配的子域收到它，但仍受其他 Cookie 条件约束。属性处理会忽略一个前导点，它并不是另一种通配符功能。只有那些更宽的接收方确实需要这个值，才应扩大作用域。 设置 Cookie 的主机不能指定无关的兄弟域：app.example.com 不能设置 Domain=shop.example.com。浏览器还会应用公共后缀限制，因此仅检查字符串后缀并不是完整实现。下面模型只处理已知的示例主机名，明确不实现公共后缀查找、国际化域名转换与 IP 地址规则；不能把这个演示直接复制成认证系统的 Cookie 库。 端口不是 Cookie 边界。属于 app.example.com 的合格 Cookie 可以发送到该主机的另一个端口，即使端口变化意味着 Web 来源已经变化。因此，意料之外的端口服务也必须纳入信任评估。把不可信应用放在不同路径或端口，并不能获得真正分开 Cookie 主机所带来的隔离，host-only 也不等于完整的同源限制。 ...

懒加载把暂时用不到的工作推迟到更合适的时机。对于 HTML 图片，loading="lazy" 允许浏览器按照自己的策略，等图片接近视口时再发起请求。长文章因此可能减少初始传输量，但这个属性只是调度输入，并不保证每一张尚未进入屏幕的图片都绝对不会下载。能否节省请求，需要观察实际浏览器行为。 让浏览器调度普通图片 原生方式直接使用真实的 src 或 srcset，不必把地址隐藏在自定义属性里，也不必仅为基础懒加载编写滚动处理器。加载距离由浏览器决定，还可能随实现及连接条件调整。作者不能通过 loading 属性直接配置原生距离阈值。使用 IntersectionObserver 的应用方案有另一套控制方式，同时也增加了程序需要承担的调度和兼容责任。 首屏必需的图片应保持及时加载，尤其是主要展示图。如果对决定最大可见内容的图片使用延迟加载，真正有用的画面可能更晚出现。反过来，为刻意延迟的图片添加 preload，也可能提前触发下载，抵消预期节省。应根据图片角色和实测结果选择，而不是给页面所有资源统一贴上同一种策略。 明确填写图片原始 width 和 height，可以让浏览器在下载之前预留宽高比例。响应式样式仍然能够缩小实际宽度，并自动保持高度比例。缺少有效尺寸时，图片最初可能几乎不占空间，既影响哪些内容被认为接近视口，也可能在图片到达后把正文突然推开。图片无法显示时，准确的替代文字仍然是阅读体验的一部分，不能只顾请求数量。 坏掉的样子 只等页面 load 事件结束，可能漏掉尚未完成的懒加载图片。浏览器可以在远处图片未下载完时结束页面加载事件，因此应分别检查图片完成状态、自然尺寸、服务端请求及滚动后的真实显示。请求已经失败与请求尚未开始是不同状态；两者最初都可能没有解码后的像素，不能只凭一项尺寸判断根因。 没有编写页面脚本，不等于在浏览器中禁用了脚本。MDN 说明，作为防跟踪措施，图片的这种延迟行为需要浏览器启用脚本。普通静态 HTML 无须额外编写 JavaScript 就可以使用，但把浏览器脚本整体关闭之后，不能继续假定请求时机完全相同。应按站点实际支持的环境验证，不宣称所有配置都能获得一样的节省。 loading 属性只作用于支持它的元素，不能直接控制任意 CSS 背景图。content-visibility 主要用于跳过部分渲染工作，也不承诺相关网络请求全部延后。快速滚动与慢连接组合时，原生调度仍可能来不及让图片及时到达。评估中需要查看空白占位持续多久以及布局是否稳定，不能把初始请求减少当成用户体验必然改善。 快速验证 本轮复核没有重新运行 HTTP 服务或浏览器滚动检查；上述 Chrome 结果属于此前记录的运行。 将下面代码保存为 lazy-images.py，运行 python3 lazy-images.py。Python 3 命令验证本地页面和两张图片都能返回成功响应，但输出中的 native_loading_tested_by_cli 明确为假。普通 HTTP 客户端读取 HTML，并不会执行浏览器图片调度器，因此该命令本身不能证明已经发生原生懒加载。 ...

Content-Type 描述发送方打算提供的表示，但它不会检查正文、转换字节，也不保证所有接收方都采取相同的处理方式。可靠的接口需要让序列化结果、媒体类型声明和消费者的预期相互吻合。这个要求不仅适用于成功响应，也适用于认证失败、代理报错和应用异常等不同的返回路径。 描述表示，而不是文件名 对于携带正文的普通响应，application/json 表示 JSON 数据，text/html 表示 HTML。类型描述的是解除内容编码之后的数据格式。因此，一份经过 gzip 压缩的 JSON 响应仍然声明 Content-Type: application/json，同时用 Content-Encoding: gzip 说明压缩。内容编码属于表示的属性，不等于 HTTP 消息如何分帧；例如分块传输编码处理的是另一层问题。修改文件扩展名或响应头都不会自动完成这些转换。 媒体类型由主类型、子类型以及可选参数构成。主类型和子类型不区分大小写，参数是否有意义则取决于对应媒体类型的定义。消费者应使用已有的头字段解析接口，不要把完整字段与一个固定字符串直接比较。同时必须单独检查字段是否存在，因为部分解析器会给缺失类型提供默认值，掩盖服务端漏发元数据的事实。多个相互冲突的类型字段也不是合法的候选列表，而是需要在源站或代理处修正的缺陷。 对于 UTF-8 编码的 HTML，text/html; charset=utf-8 同时描述格式与字符编码。但不能据此给每一种文本格式统一追加字符集参数。RFC 8259 要求非封闭生态系统之间交换的 JSON 使用 UTF-8，而 application/json 的媒体类型注册没有定义 charset 参数。接收方不能靠另加一个参数，就把不符合该交换约定的字节变成合规 JSON。类型参数必须服从格式本身的规定，而不是套用全站通用字符串。 坏掉的样子 常见故障是反向代理把 API 响应替换成 HTML 登录页，却仍返回成功状态码。客户端一上来就调用 JSON 解析器，只能看到语法错误，反而隐藏了“收到另一种表示”这个更有价值的线索。另一种情况恰好相反：应用错误处理器输出 HTML，却沿用了成功路径的 JSON 响应头。这时仅检查声明也会放行无效正文。所以，状态码、响应元数据和实际字节是三个需要一起检查的证据。 ...