news 2026/10/27 2:04:34

告别浏览器扩展MV3静默失灵：受限标头拦截、凭据栈装配与CSRF协商防御实战

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
告别浏览器扩展MV3静默失灵：受限标头拦截、凭据栈装配与CSRF协商防御实战

文章目录

  • 1. 现场还原：AI生成的MV3代码为何频繁遭遇“幽灵失灵”
    • 1.1. 从普通网页到扩展后台的认知错位
    • 1.2. 真实崩溃现场：静默剥离与假性 401 报错
  • 2. 根因深潜：解剖浏览器网络内核与受限标头沙箱
    • 2.1. W3C Fetch 规范中的受限标头禁区
    • 2.2. Service Worker 隔离沙箱与凭据隐蔽丢失
    • 2.3. 服务端防重放机制与 CSRF 协商断裂
  • 3. 架构重塑：从代码直写到内核级声明式网络装配
    • 3.1. 跨域凭据栈契约：host_permissions 与 credentials
    • 3.2. declarativeNetRequest 动态规则热加载机制
    • 3.3. 二阶段状态机：元数据嗅探与 CSRF 动态握手
  • 4. 生产级实战：构建高可用的MV3跨域写入防御管道
    • 4.1. 动态声明式规则管理器源码落地
    • 4.2. 具备重试退避与握手协商的统一请求管道
    • 4.3. 自动化架构自检门禁与验证闭环
  • 5. 总结与第一性原理沉淀
    • 5.1. 浏览器扩展跨域网络方案全景对比
    • 5.2. MV3 扩展架构演进的三大硬核军规

前言：
在借助 AI 编程助手开发现代 Chrome 扩展（Manifest V3）时，跨域凭据写入与后台静默失灵是困扰大量开发者的典型痛点。大模型往往习惯性给出在普通前端页面看似可行的 Fetch 代码，殊不知一旦置于 MV3 Service Worker 沙箱，Cookie、Referer等核心鉴权标头便会被浏览器网络内核静默剥离，进而引发无明确报错却鉴权失败的“幽灵故障”。本文基于真实浏览器伴侣插件与自动化分发系统的工程排错实战，深度剖析 W3C 安全受限标头拦截机理，交付基于declarativeNetRequest的内核级标头改写、全量凭据栈装配与二阶段 CSRF 动态协商的完整防御体系，彻底终结 MV3 后台静默失灵死结。
个人主页：艺杯羹

1. 现场还原：AI生成的MV3代码为何频繁遭遇“幽灵失灵”

在现代化工具链与多平台分发场景中，浏览器扩展承担着连接用户宿主会话与外部开放 API 的关键枢纽作用。

随着 Chrome 全面强制推行 Manifest V3（MV3）架构规范，后台常驻的 Background Page 被完全废除，取而代之的是无 DOM 树、事件驱动且随用随销的 Service Worker。这一底层宿主变迁，使得大量由 AI 编程工具基于旧时代语料生成的网络请求逻辑陷入了灾难性的“假性成功”与“静默瘫痪”。

1.1. 从普通网页到扩展后台的认知错位

当要求 AI 编写一段在扩展后台向第三方业务系统保存草稿或提交数据的逻辑时，大模型往往会自信地生成如下标准的 Fetch 代码片段：

// AI 助手在 Service Worker 中生成的常规网络请求代码asyncfunctionsaveDraftToTargetPlatform(articleData,userCookie){consttargetUrl='https://api.target-platform.com/v1/article/draft/save';// 开发者直觉：既然拿到了用户的 Cookie，直接通过自定义 Header 传入constresponse=awaitfetch(targetUrl,{method:'POST',headers:{'Content-Type':'application/json','Cookie':userCookie,// 尝试显式注入鉴权 Cookie'Referer':'https://target-platform.com/editor/writer',// 尝试伪造防盗链溯源'Origin':'https://target-platform.com'// 尝试绕过服务端源站校验},body:JSON.stringify(articleData)});returnawaitresponse.json();}

在本地开发调试阶段，这段逻辑表面上逻辑闭环、参数完备。然而一旦在真实的 Chrome MV3 扩展中加载运行，灾难便随之降临。

1.2. 真实崩溃现场：静默剥离与假性 401 报错

打开扩展的 Service Worker 控制台（Inspect Background Service Worker），在执行上述提交逻辑时，控制台立刻刷出了数行刺目的黄色警告，紧接着便是目标接口的鉴权拒绝响应：

[DevTools Console] ⚠️ Refused to set unsafe header "Cookie" ⚠️ Refused to set unsafe header "Referer" ⚠️ Refused to set unsafe header "Origin" [Network Inspector] Request URL: https://api.target-platform.com/v1/article/draft/save Request Method: POST Status Code: 401 Unauthorized Remote Address: 104.21.56.88:443 [Response Body] { "code": 401, "success": false, "message": "用户登录凭证已失效或未提供有效 Session，操作已被拒绝", "data": null }

许多开发者在初次遭遇此报错时，往往会误以为是传入的userCookie字符串格式不规范或已过期，于是反复检查登录态，甚至陷入不断重新登录、抓包比对的死循环。

更为致命的是，若开发者向 AI 反馈“接口返回 401 且提示跨域与标头错误”，大模型通常会给出极其危险的“投机式建议”：给 Fetch 请求添加mode: 'no-cors'。

一旦盲目采纳mode: 'no-cors'，请求方法立刻被限制在简单的 GET/HEAD，所有自定义标头被全量剔除，返回的 Response 对象变成完全不透明的 Opaque Response（状态码强制归零，无法读取响应体内容）。整个网络链路彻底丧失可观测性，系统彻底陷入深不可测的静默失灵黑盒。

2. 根因深潜：解剖浏览器网络内核与受限标头沙箱

要根治这一工程顽疾，不能停留在尝试不同 Fetch 配置的盲目碰运气，而必须从浏览器底层安全边界与 W3C 网络规范的第一性原理进行解剖。

2.1. W3C Fetch 规范中的受限标头禁区

在 W3C 标准的 Fetch Specification 中，明确定义了一份名为Forbidden Header Names（受限标头列表）的安全清单。这份清单包含但不限于：

  • Cookie/Cookie2
  • Referer
  • Origin
  • Host
  • User-Agent
  • DNT
  • 任何以Sec-或Proxy-开头的标头

浏览器网络内核强制规定：任何运行在客户端环境中的 JavaScript 脚本代码（包括普通页面 JS、Web Worker 以及扩展 Service Worker），均绝对无权通过代码层面的 Headers API 显式写入或覆写受限标头。

当 JavaScript 引擎调用底层的XMLHttpRequest.setRequestHeader或fetch(url, { headers })遇到受限标头时，浏览器的行为策略是静默忽略并丢弃该字段，同时向控制台输出Refused to set unsafe header警告，但绝对不会中断请求的派发。

这意味着，代码发出的 HTTP 数据包并不是被拦截在客户端，而是以一种“被扒光了关键鉴权与溯源标头”的裸露状态飞向了服务端。目标服务端面对一个毫无身份凭据的请求，自然只能冷酷地抛出401 Unauthorized或403 Forbidden。

2.2. Service Worker 隔离沙箱与凭据隐蔽丢失

在过去的 Manifest V2 架构中，扩展可以配置拥有完整 DOM 与 Window 对象的 Background 页面，甚至可以通过跨域 XMLHttpRequest 绕过许多限制。但在 Manifest V3 中，Service Worker 是一个纯粹的、无 DOM 的沙箱化工作线程。

在默认情况下，JavaScript 的fetch()函数遵循同源凭据策略（credentials: 'same-origin'）。当扩展 Service Worker 向目标三方平台发起跨域 POST 请求时，浏览器出于隐私保护与防跨站跟踪机制，默认严禁自动携带宿主浏览器中已存在的任何目标站 Cookie。

一边是代码层直接设置Cookie遭到内核静默丢弃，另一边是底层网络栈默认拒绝携带已存 Cookie，两道安全防线同时闭合，导致请求在物理链路上彻底处于“凭据真空状态”。

2.3. 服务端防重放机制与 CSRF 协商断裂

很多团队在初步解决了 Cookie 附带问题后，立刻迎来了第二道难以逾越的高墙：403 CSRF Token 缺失或失配。

现代成熟平台为了防御跨站请求伪造（CSRF）攻击，普遍推行双重提交或防重放令牌机制。除了在 Cookie 中验证 Session，服务端还要求在 POST 请求头中附带动态签名的x-csrf-token，或者在 Payload 体内嵌入表单 Token。

由于 AI 生成的代码往往将“保存草稿/发布内容”视作孤立的单次 POST 操作，完全割裂了客户端与服务端的上下文状态协商，导致请求即使挂载了登录态，依然因未完成前置 Token 握手而被服务端的 WAF 或安全拦截网阻绝。

3. 架构重塑：从代码直写到内核级声明式网络装配

既然客户端 JavaScript 代码受制于 W3C 规范无法直接触碰受限标头，那么生产级的工程解法就必须转向操作系统与浏览器内核赋权机制——利用 Chrome 提供的系统级权限与声明式网络请求引擎（Declarative Net Request），实现由外而内的沙箱穿透。

3.1. 跨域凭据栈契约：host_permissions 与 credentials

在 MV3 架构中，要让浏览器网络底层在跨域请求中自发调取并挂载受保护的 Session Cookie，必须完成两项声明式契约：

其一，在manifest.json中明确声明目标域名的主机权限作用域（host_permissions）；
其二，在发起 Fetch 请求时显式声明凭据模式为credentials: 'include'。

{"manifest_version":3,"name":"SecurePublisherCompanion","version":"1.0.0","permissions":["declarativeNetRequest","declarativeNetRequestWithHostAccess","cookies","storage"],"host_permissions":["https://api.target-platform.com/*","https://*.target-platform.com/*"],"background":{"service_worker":"background.js","type":"module"}}

当host_permissions覆盖了目标 URL 时，浏览器网络栈对该域名的安全沙箱进行合规穿透。此时配置credentials: 'include'，浏览器在底层组装 TCP 报文时，便会自动从本地安全存储的 Cookie 数据库中，调取符合该域名匹配规则的全部合规 Cookie 并自动装配在Cookie报文头中，彻底绕过了脚本直接设定的拦截限制。

3.2. declarativeNetRequest 动态规则热加载机制

虽然解决 Cookie 自动挂载迈出了关键一步，但诸如Referer和Origin等溯源防盗链标头依然无法通过客户端 Fetch 伪造。

此时，必须引入 MV3 的核心杀手锏：chrome.declarativeNetRequest。该 API 允许扩展在浏览器网络管道中注册声明式拦截规则。这些规则由浏览器内核底层执行，不受 W3C 客户端脚本限制的影响。

// 动态规则配置示例：由内核在网络层重写标头construle={id:1001,priority:1,action:{type:'modifyHeaders',requestHeaders:[{header:'Referer',operation:'set',value:'https://target-platform.com/editor/writer'},{header:'Origin',operation:'set',value:'https://target-platform.com'}]},condition:{urlFilter:'https://api.target-platform.com/v1/article/*',resourceTypes:['xmlhttprequest']}};

通过将标头改写逻辑从脆弱的脚本代码下沉至浏览器声明式引擎，请求发出前由内核完成报文重组，目标服务端收到的报文在标头格式、来源路径与凭据结构上与用户在真实网页内点击毫无二致。

3.3. 二阶段状态机：元数据嗅探与 CSRF 动态握手

为了彻底根除 403 CSRF 拦截，必须确立二阶段状态机架构。任何针对第三方平台的写操作，严禁盲目直接发起单回合写入，而必须严格遵循以下三阶段流水线：

  • 阶段一（元数据探针与登录态嗅探）：以credentials: 'include'向目标平台页面发起无副作用的探针探测（GET 请求），一方面验证用户凭证是否真正存活，另一方面利用 DOM/正则引擎从响应 HTML 或 Set-Cookie 中动态提取当前的防重放 CSRF 令牌。
  • 阶段二（内核规则热加载）：针对本次写操作的目标接口，动态注册专属于该操作的 DNR 规则，注入合规的溯源标头。
  • 阶段三（原子化装配与安全提交）：将业务 Payload 与阶段一提取的 CSRF Token 紧密绑定，发起物理写请求，并在完成通信后即时清理临时 DNR 规则，保证零副作用残留。

4. 生产级实战：构建高可用的MV3跨域写入防御管道

下面给出一套在真实高对抗场景中锤炼成型的生产级实现方案，包含声明式网络规则管理器与健壮的二阶段安全传输管道。

4.1. 动态声明式规则管理器源码落地

在频繁进行多平台分发的场景中，全局静态注册规则容易引发不同平台间的标头冲突。推荐采用轻量级动态规则管理器，实现“按需注册、用完即焚”的生命周期控制：

/** * MV3 声明式网络规则管理器 * 负责在浏览器底层网络栈动态挂载与卸载受限标头重写规则 */exportclassDeclarativeRuleManager{staticRULE_ID_OFFSET=20000;/** * 为指定请求目标注入底层标头重写规则 * @param {string} urlPattern 匹配目标 URL 正则表达式或通配串 * @param {Object} customHeaders 需要在网络底层注入的受限标头键值对 * @returns {Promise<number>} 分配的规则 ID */staticasyncattachHeaders(urlPattern,customHeaders){construleId=this.RULE_ID_OFFSET+Math.floor(Math.random()*9999);constrequestHeaders=Object.entries(customHeaders).map(([key,value])=>({header:key,operation:'set',value:String(value)}));constdynamicRule={id:ruleId,priority:2,action:{type:'modifyHeaders',requestHeaders:requestHeaders},condition:{urlFilter:urlPattern,resourceTypes:['xmlhttprequest']}};try{// 注册动态规则至 Chrome 网络内核awaitchrome.declarativeNetRequest.updateDynamicRules({addRules:[dynamicRule],removeRuleIds:[ruleId]// 确保 ID 不发生冲突碰撞});returnruleId;}catch(error){console.error(`[DNR 注入失败] 无法为${urlPattern}应用声明式规则:`,error);thrownewError(`网络内核规则注入异常:${error.message}`);}}/** * 任务完成后安全回收规则，防止标头规则全局泄露与污染 * @param {number} ruleId 需要回收的规则 ID */staticasyncreleaseRule(ruleId){if(!ruleId)return;try{awaitchrome.declarativeNetRequest.updateDynamicRules({removeRuleIds:[ruleId]});}catch(cleanupError){console.warn(`[DNR 回收警报] 规则 ID${ruleId}释放失败:`,cleanupError);}}}

4.2. 具备重试退避与握手协商的统一请求管道

针对复杂的跨域鉴权与防重放约束，以下代码封装了完整的二阶段状态机客户端。集成了探针预检、Token 抽取、DNR 挂载、指数退避重试与结果验真：

import{DeclarativeRuleManager}from'./declarativeRuleManager.js';/** * 具备生产级自愈能力的 MV3 安全传输客户端 */exportclassSecureMV3Client{constructor(config){this.baseUrl=config.baseUrl;this.probeUrl=config.probeUrl;// 用于握手提取 CSRF 的探针页面this.referer=config.referer;this.origin=config.origin;}/** * 阶段一：静默探针握手，提取防重放 CSRF 令牌与前置健康状态 */asyncnegotiateSessionContext(){try{constprobeResponse=awaitfetch(this.probeUrl,{method:'GET',credentials:'include',// 必须自动携带宿主 Cookieheaders:{'Accept':'text/html,application/xhtml+xml,application/xml'}});if(!probeResponse.ok){thrownewError(`握手探针失败，HTTP 状态码:${probeResponse.status}`);}consthtmlContent=awaitprobeResponse.text();// 正则提取常见 CSRF Token 模式（如 meta 标签或全局脚本变量）constmetaMatch=htmlContent.match(/<meta\s+name=["']csrf-token["']\s+content=["']([^"']+)["']/i);constscriptMatch=htmlContent.match(/window\._csrfToken\s*=\s*["']([^"']+)["']/i);constcsrfToken=metaMatch?metaMatch[1]:(scriptMatch?scriptMatch[1]:null);return{isAlive:true,csrfToken:csrfToken};}catch(err){console.error('[握手协商失败] 无法获取会话上下文:',err);thrownewError(`用户会话无效或网络中断:${err.message}`);}}/** * 阶段二与阶段三：结合 DNR 改写与原子载荷提交 */asyncexecuteSecureWrite(apiPath,payload,maxRetries=2){constfullTargetUrl=`${this.baseUrl}${apiPath}`;// 1. 执行前置状态协商constsessionContext=awaitthis.negotiateSessionContext();if(!sessionContext.isAlive){thrownewError('目标平台登录态失效，已自动拦截后续写入');}// 2. 挂载内核级 DNR 规则，注入合法溯源标头constcustomHeaders={'Referer':this.referer,'Origin':this.origin};construleId=awaitDeclarativeRuleManager.attachHeaders(fullTargetUrl,customHeaders);letattempt=0;try{while(attempt<=maxRetries){attempt++;try{// 组装携带 CSRF 的请求体与头信息constrequestHeaders={'Content-Type':'application/json','Accept':'application/json, text/plain, */*'};if(sessionContext.csrfToken){requestHeaders['x-csrf-token']=sessionContext.csrfToken;}constresponse=awaitfetch(fullTargetUrl,{method:'POST',credentials:'include',// 核心保证：底层自动挂载 Cookieheaders:requestHeaders,body:JSON.stringify(payload)});// 拦截典型的鉴权异常与频控异常if(response.status===401||response.status===403){consterrBody=awaitresponse.text();thrownewError(`鉴权阻断 (HTTP${response.status}):${errBody}`);}if(!response.ok){thrownewError(`服务端异常响应: HTTP${response.status}`);}constresult=awaitresponse.json();returnresult;// 成功交付物理结果}catch(innerError){if(attempt>maxRetries)throwinnerError;constbackoffDelay=attempt*800;console.warn(`[安全传输重试] 第${attempt}次失败，${backoffDelay}ms 后重试:`,innerError.message);awaitnewPromise(resolve=>setTimeout(resolve,backoffDelay));}}}finally{// 3. 严格执行规则生命周期清理，用完即焚awaitDeclarativeRuleManager.releaseRule(ruleId);}}}

4.3. 自动化架构自检门禁与验证闭环

为了防止团队成员或 AI 助手在后续迭代中再次写出“直接向 fetch headers 塞 Cookie”的代码，可以在项目的持续集成管道或 Pre-commit 阶段挂载静态规则扫描。

以下是一段基于 Node.js 正则扫描的 AST 门禁脚本，一旦发现违规代码直写立即阻断构建：

// scripts/lint-unsafe-headers.jsimportfsfrom'fs';importpathfrom'path';constFORBIDDEN_HEADERS=['cookie','cookie2','referer','origin','user-agent','host'];constSRC_DIR=path.resolve(process.cwd(),'src');functionscanFile(filePath){constcontent=fs.readFileSync(filePath,'utf-8');lethasError=false;FORBIDDEN_HEADERS.forEach(header=>{// 匹配类似 'cookie': 或 "referer": 的对象属性声明constregex=newRegExp(`['"]${header}['"]\\s*:`,'gi');letmatch;while((match=regex.exec(content))!==null){console.error(`❌ [安全门禁阻断] 在文件${filePath}发现违规受限标头硬编码: "${match[0]}"`);console.error(`👉 提示：MV3 客户端脚本无法设置受限标头，请改用 DeclarativeRuleManager。`);hasError=true;}});returnhasError;}functiontraverseDir(dir){letfailed=false;constfiles=fs.readdirSync(dir);for(constfileoffiles){constfullPath=path.join(dir,file);if(fs.statSync(fullPath).isDirectory()){if(traverseDir(fullPath))failed=true;}elseif(file.endsWith('.js')||file.endsWith('.ts')){if(scanFile(fullPath))failed=true;}}returnfailed;}console.log('[+] 正在执行 MV3 网络规范静态安全门禁扫描...');consthasViolation=traverseDir(SRC_DIR);if(hasViolation){console.error('\n🚨 扫描到潜在的 MV3 静默失灵隐患，构建已被强制终止！');process.exit(1);}else{console.log('✅ MV3 网络请求规范扫描通过，无受限标头滥用。');}

5. 总结与第一性原理沉淀

在现代浏览器扩展生态中，架构的每一次版本跃迁都伴随着底层安全沙箱的深度收紧。面对日益严苛的宿主边界，工程团队必须摒弃“脚本万能”的传统思维。

5.1. 浏览器扩展跨域网络方案全景对比

架构策略标头控制力Cookie 携带机制防盗链穿透CSRF 防御兼容适用场景与工程公信力
代码层直接伪造（AI 常见写法）极低（内核强制剥离受限标头）无法携带宿主 Cookie，退化为匿名裸请求彻底失败（Referer 被静默丢弃）无法应对，引发 403 阻断反模式：引发假性 401 报错与静默失灵死结
no-cors 投机绕过无（所有自定义标头全被清除）无法读取响应体，沦为 Opaque 黑盒无法控制完全失效灾难模式：掩盖真实网络异常，系统不可观测
内容脚本（Content Script）中转中等（受页面 CSP 与同源限制影响）继承宿主会话，但无法绕过页面 CSP 策略受当前页面 URL 强绑定限制需在页面注入上下文，侵入性极高妥协方案：仅适用于已处于活动状态的目标 Tab
DNR 动态规则 + 凭据栈（生产标准）完全控制（浏览器内核声明式注入）自动透传宿主合规 Cookie（credentials: include）完美穿透（内核精准替换 Referer/Origin）二阶段握手协商，动态绑定 Token 闭环生产级最佳实践：兼具极致稳定性与零副作用

5.2. MV3 扩展架构演进的三大硬核军规

经历数十次版本重构与跨平台对抗实战，可以提炼出指导现代浏览器扩展开发的三条核心法则：

  • 安全边界不变量：永远不要试图在 JavaScript 脚本代码中对抗浏览器的安全规范。受限标头的剔除属于底层内核行为，唯有通过host_permissions建立信任作用域，并借助declarativeNetRequest将修改意图托管给浏览器网络内核，才是唯一合法有效的穿透路径。
  • 状态协商前置法则：在针对第三方平台的写操作链路中，不存在单次回合的“即时写入”。任何缺乏握手探针的盲写操作，其本质都是脆弱的赌博。建立“探针探测、凭据验证、令牌提取、原子提交”的确定性状态机，是消除网络假成功与幽灵异常的基石。
  • 动态规则用完即焚原则：声明式网络请求虽然赋予了扩展改写网络报文的强大能力，但必须谨防规则泄漏导致的全局流量污染。将 DNR 规则的生命周期与具体业务操作严格绑定，在finally结构中确保规则的安全释放，才能保持扩展运行时的长期纯净与健壮。
版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/10/27 2:04:33

13.0 mtk 音量等级从15改为25

1.前言 在系统音量等级默认只有15级，客户需要需要改到25级,接下来和音量曲线一起修改看下如果修改完成客户要求 2.mtk 音量等级从15改为25核心类 frameworks/base/services/core/java/com/android/server/audio/AudioService.java vendor/mediatek/proprietary/external/au…

作者头像 李华
网站建设 2026/10/27 2:03:42

二周小结！

Java 学习周记 第二周 这周学了什么 流程控制收了个尾&#xff0c;然后一路走数组、方法&#xff0c;最后进了面向对象。 进度是跟上了&#xff0c;但没学明白。数组、方法、封装、重载这几块在脑子里搅成一团&#xff0c;单拎一个词出来能说两句&#xff0c;真让我从头写一段…

作者头像 李华
网站建设 2026/10/27 2:03:00

微信小程序实战：双层 wx:for 渲染九九乘法表

一、需求分析本次案例我们利用小程序列表渲染 wx:for 来实现九九乘法表&#xff0c;核心需求&#xff1a;页面展示标题 九九乘法表整体纵向从上到下排布&#xff0c;每一行内部横向从左到右排列使用双层循环&#xff08;双层 wx:for&#xff09;&#xff0c;搭配列表渲染、条件…

作者头像 李华
网站建设 2026/10/27 2:02:57

一文看懂 AI Agent 工作原理：从大脑到手脚

一、Agent 不是更会聊的机器人 很多人把 AI Agent 当成「更高级的聊天机器人」&#xff0c;其实本质不同&#xff1a;它会自己干活。 一个 Agent 由三部分组成&#xff1a; 大脑&#xff1a;大模型&#xff0c;负责推理与规划手脚&#xff1a;工具&#xff08;Tools&#xff09…

作者头像 李华
网站建设 2026/10/27 2:02:53

微信小程序 scroll-view 组件实现纵向与横向滚动

前言scroll-view是小程序滚动视图组件&#xff0c;用于实现局部区域滚动。动。本案例通过 scroll-view 完成纵向滚动与横向滚动两个场景&#xff0c;演示scroll-into-view、scroll-left等属性&#xff0c;以及bindscrolltoupper、bindscrolltolower、bindscroll滚动事件&#x…

作者头像 李华
网站建设 2026/10/27 2:02:53

10.25学习笔记

创建数据库create database 名称删除数据库drop database 名称查询指定库show create database 名称;修改数据库alter database 名称&#xff1b;选择数据库use 名称&#xff1b;------------------------------------------------------------------------------------------…

作者头像 李华