- 博客(35)
- 收藏
- 关注
RSS订阅原创 软著 vs 发明专利：从真实驳回案例看如何构建技术护城河
对于技术人来说，代码可能会过时，但底层的架构思想和被法律保护的技术方案是长期的资产。从下一次需求评审开始，尝试用“交底书四步法”去拆解你的技术方案，沉淀属于你的硬核资产。第一篇：程序员如何申请技术发明专利？从60+政务项目中提炼的“交底书四步法”第二篇：慎用大模型代写专利！技术交底书撰写的三大红线与避坑指南第三篇：专利交底书实战拆解：以真实交底书为例。
2026-11-06 08:34:20
89
原创 专利交底书实战拆解：以真实交底书为例
很多开发者在写交底书时，容易陷入“堆砌技术名词”的误区。本文以已提交的专利《一种前端组件生成、演化方法以及自适应演化系统》为例，拆解高质量交底书的四大核心模块。
2026-11-06 08:32:18
124
原创 慎用大模型代写专利！技术交底书撰写的三大红线与避坑指南
随着大语言模型（LLM）的普及，不少开发者尝试用 AI 辅助生成专利交底书。然而，专利审查具有极高的严谨性与法律属性。本文结合实际案例，剖析 AI 撰写交底书的致命风险。
2026-11-05 10:20:34
226
原创 程序员如何申请技术发明专利？从60+政务项目中提炼的“交底书四步法”
本文分享程序员撰写专利交底书的“四步法”：明确修改对象、揭示技术痛点、详述核心方案（含流程图/架构图）、量化技术效果。强调将业务优化转化为专利的关键在于聚焦“解决特定技术问题”，并提供标准化结构模板。建议开发者以工程化思维提炼技术沉淀，提升简历竞争力。下期将揭秘AI辅助撰写的三大风险。
2026-11-05 10:18:54
178
原创 【系列收官】Web实时异常监控系统：异常闭环流程、工程取舍，与Sentry方案横向对比总结
很多团队在设计监控系统的时候，把重心全部放在异常采集、日志存储、图表展示、告警推送，误以为告警消息发出就代表整个流程结束。但告警通知仅仅只是问题处理的起点，而非终点。一条线上异常，从被SDK捕获、上报服务端、经过分析引擎统计判断、触发告警通知开发，还需要经过开发定位、代码修复、版本发布，最后确认故障消失，才算真正完成完整闭环。缺少闭环管理，会出现大量历史异常堆积，旧故障修复之后告警依然反复触发，部分问题长期被遗忘无人处理。
2026-09-05 13:17:21
172
原创 Web监控告警不要乱轰炸：自定义基线、三级分级报警、多渠道通知体系设计方案
很多自研或者商用监控系统，最大的痛点不是采集不到数据，而是告警策略失控。线上稍微出现一点波动，就疯狂推送大量消息。JS少量报错、个别用户接口超时就触发告警，企业微信消息连续刷屏，短信不断推送。久而久之，开发人员会对告警消息产生疲劳，甚至直接屏蔽监控通知。等到真正发生重大线上故障的时候，反而没有人关注告警，监控系统也就失去了本身的价值。告警不等于只要出现异常就通知人。告警模块要解决几个核心问题：第一，区分故障严重程度，严重故障需要快速触达，轻微问题仅做记录不需要高频打扰；
2026-09-05 13:16:58
287
原创 Web监控系统：页面性能、API接口指标统计分析，可视化大盘设计思路
<think>我们根据内容生成摘要，需≤150字。概括核心：页面性能聚合统计、慢页面识别、API成功率与耗时分析、可视化大盘设计、工程难点，预告下篇。</think>本文介绍Web监控系统第五篇，聚焦页面性能与API分析：包括性能指标聚合、慢页面识别、接口成功率与耗时统计，以及可视化大盘的图表下钻与预聚合设计，并探讨海量日志处理难点，预告告警模块。
2026-09-04 10:42:11
240
原创 线上JS报错如何快速定位源码位置？异常分析引擎、Source‑Map反解与问题归类实现思路
<think>我们根据要求，将文章内容压缩成不超过150字的摘要。要包括核心要点：服务端JS Error分析引擎，存储选型LevelDB，聚合统计，严重程度判定，兼容性识别，Source-Map还原，Git-Blame责任人关联。语言简洁。</think>本系列第四篇介绍服务端JS Error分析引擎：以LevelDB存储海量日志，聚合同类异常并依据次数与用户数比值判定严重等级，自动识别操作系统/浏览器兼容性问题，通过Source-Map还原压缩堆栈至源码位置，再结合Git-Blame关联候选责任人。
2026-09-04 10:41:54
286
原创 前端海量异常日志上报优化：IndexedDB做本地缓存，解决上报阻塞、丢日志问题
客户端SDK完成异常采集之后，很多人第一直觉就是：拿到异常数据，直接发起HTTP请求上报到后端服务。在异常数量很少的时候，这种简单直报的方式可以正常工作。但是放到真实线上复杂场景，会暴露出非常多棘手的问题。想象这样一类线上故障场景：业务页面出现全局性JS报错，用户每一次交互都会触发一条异常日志。此时页面会在短时间内批量产生几十上百条异常，如果每一条异常都立刻发起fetch或者XMLHttpRequest请求上报。
2026-09-03 08:36:25
308
原创 自研前端监控SDK设计：JS错误、页面性能、API接口三类异常如何完整采集
一套监控系统的数据根基来源于客户端SDK。后端的分析、告警、可视化全部依赖前端采集上来的原始日志，如果采集环节存在缺陷、数据丢失或者采集信息不全，那么后续所有的分析工作都会变成无源之水。在SDK开发过程中，最容易走入的误区就是过度侵入业务代码。如果需要业务大规模修改原有业务逻辑、埋点改造，会极大提升接入成本，业务团队的接入意愿会大幅降低。因此SDK设计第一原则就是低业务入侵，尽可能做到少量配置即可完成接入，不需要修改大量业务业务代码。同时，SDK本身不能对业务页面产生负面影响。
2026-09-03 08:36:02
425
原创 线上Web异常发现为什么总是滞后？一套自研Web实时异常分析监控系统整体架构拆解
<think>我们根据要求，需要生成≤150字的文章摘要。文章内容是关于Web端实时异常分析监控系统设计，包括痛点、架构、能力等。摘要需要概括核心内容。注意字数限制。</think>本文围绕Web端实时异常分析监控系统，剖析线上异常排查滞后、复现难、数据割裂等痛点，对比现有方案局限，提出自研分层架构：客户端SDK采集、IndexedDB缓存、双通道上报，后端分析、告警与闭环。系统支持多维度分析、自定义告警、问题追踪，并明确适用边界。
2026-09-02 09:37:25
242
原创 【系列收官】前后端实时协同防护：WebSocket状态同步、分布式熔断与整套方案落地权衡总结
前面文章分别介绍了前端侧、服务端侧各类防护能力。如果前端检测到调试、篡改等异常，服务端无法及时感知；服务端识别非法请求、风险会话，前端也不能立刻销毁内存中的密钥与敏感上下文。前后端防护互相割裂，攻击者可以逐个击破单点防御。想要实现真正的全链路对抗，就需要建立一条前后端实时通信通道，完成状态双向同步，实现分布式联动熔断，将前端、服务端防护串联成一个完整的防御整体。分析传统单点防护的短板，引出协同式多层防御整体架构；前端业务模块化拆分，基于 DAG 图谱做模块依赖校验、时间窗口风险识别；
2026-09-02 08:40:35
285
原创 不只校验单个接口：基于接口调用图谱的全链路请求合法性校验方案
<think>我们根据要求，需生成≤150字的摘要。需要概括内容：本文聚焦Web前端安全，提出服务端接口调用图谱与会话状态机，解决跳过前置流程的非法请求，并联合动态凭证、设备指纹、加密返回等。也要提及后续。字数要控制。</think>本文针对Web前端安全，提出服务端接口调用图谱与会话状态机，约束API调用顺序，拦截跳过前置流程的非法请求；并结合动态凭证、设备指纹、会话密钥加密及联合校验，构建多层防护。同时指出人工维护成本等局限，预告后续分布式熔断与落地总结。
2026-09-01 16:33:04
61
原创 解决静态Token重放攻击：浏览器设备指纹采集，与动态凭证绑定方案
<think>我们根据要求生成一篇不超过150字的摘要。内容需概括文章核心：设备指纹采集（Canvas/WebGL/Audio）、与动态凭证绑定（HMAC签名、时间戳Nonce）以抵御重放攻击，服务端多维度校验，及收益局限。注意字数限制，用中文，简洁明了。</think>本文介绍Web前端安全防护的第四篇：通过采集Canvas、WebGL、Audio等多维特征生成设备指纹，并与时间戳、随机数结合，经HMAC签名生成短期一次性动态凭证，绑定设备环境以抵御抓包重放攻击。服务端校验签名、时效、指纹一致性及Nonc
2026-09-01 16:28:51
155
原创 WASM加持Web反调试：多层混淆加密、动态加载与内存隔离熔断机制
<think>我们根据要求生成≤150字的文章摘要。需要概括主要内容：多层混淆加密、WASM加载解密、内存隔离、本地熔断，以及收益局限。控制在150字内。</think>本文介绍Web前端安全对抗的第三篇，聚焦模块加密混淆、WASM动态加载、内存隔离与本地熔断。通过控制流扁平化、字符串加密等混淆，叠加AES-GCM+RSA加密，并将解密逻辑置于WASM独立内存，防止密钥泄露；异常时触发熔断销毁敏感数据。方案提高逆向成本，但存在性能开销，需配合后端校验。
2026-09-01 16:26:24
155
原创 Web前端代码保护：核心业务代码模块化拆分，构建模块依赖DAG图谱实现动态分发
<think>我们根据要求生成摘要，不超过150字。内容聚焦模块化拆分与依赖图谱、时间窗口约束。摘要需概括核心。</think>本文介绍前端防护第二道防线：将核心业务代码模块化拆分并存放服务端，运行时按需分发，减少静态暴露。通过构建模块依赖DAG图谱约束调用顺序，并引入时间窗口机制识别断点调试等异常，同时说明开发与运行流程、收益及局限。
2026-09-01 13:47:23
157
原创 Web反调试防护新思路：传统防护为什么容易被绕过？动态代码分发+全链路验证整体架构详解
随着SPA单页应用、PWA渐进式网页应用大规模普及，越来越多的业务逻辑、数据加密、前置校验逻辑迁移到浏览器端执行。浏览器天然的开放运行环境，也带来了严峻的安全风险。攻击者可以借助浏览器开发者工具、抓包代理工具，完成断点调试、JS函数Hook、请求参数篡改、业务逻辑逆向、接口重放等操作。对于承载敏感业务的Web系统来说，核心逻辑被逆向、数据被篡改，会直接带来业务损失，同时也会带来合规层面的风险。
2026-09-01 13:41:37
816
原创 Web应用反调试的浅显思考和探索(四)
以支付流程为例，必须严格按照身份验证→订单生成→支付确认的顺序进行模块调用，若未完成身份验证就直接调用支付确认模块，系统将立即触发异常，确保业务逻辑的正确执行。在实际运行中，若模块 A 执行完毕后，超过 10 秒（可根据具体业务场景灵活调整）未触发模块 B 的调用，系统会判定为可能存在调试中断操作，进而触发熔断机制。③ 模块设计：对每个模块进行详细的设计，包括模块的接口定义、内部逻辑结构、数据处理流程等。⑤ 模块测试：对每个模块进行单元测试和综合测试，确保模块的功能正确性和稳定性。
2025-06-16 13:09:47
417
原创 Web应用反调试的浅显思考和探索(三)
现有反调试技术在实现过程中，多从前端防御或服务端防御的单个或少数几个点入手，防御层面较为单一。前端防御与服务端防御未能通过有效的方式进行整合，难以形成综合防御体系。单个防御措施的脆弱性使得攻击者容易突破防线，攻击成本较低，导致整体防御效果不佳，无法满足 Web 应用日益增长的安全需求。如何以前后端全链路协同防御的思想来进行反调试实践，是构建全面且高效的 Web 应用反调试的终极解决方案。后面的文章中会以这个思想，继续探索反调试技术。
2025-06-16 11:51:49
334
原创 Web应用反调试的浅显思考和探索(二)
通过无限debugger干扰调试的，可以通过chrom中Never pause here跳过debugger语句。或者重写setInterval过滤包含debugger的函数。通过监听浏览器窗口大小来的方式进行反调试的，只需要在开发者工具中以独立窗口打开，从而避免窗口尺寸监测。
2025-03-11 09:12:19
406
原创 Web应用反调试的浅显思考和探索(一)
在数字化高速发展的今天，Web应用已成为最常见的信息交互平台，连接着人与人、人与企业、人与政府机构等，为我们的生活和工作提供了诸多便利。随着Web应用的普及和发展，Web应用的安全性也成为了关注的焦点，如何保护Web应用的安全，避免潜在漏洞被非法利用，如何保证用户敏感信息不泄露，如何保证Web应用的核心业务逻辑、算法、技术等知识产权不泄露，如何加强系统稳定性等都是需要关注的重点。通过采取有效的反调试手段，能够保护Web应用的数据安全、业务逻辑不泄密、提升用户体验，从而提高Web应用的整体安全性。
2025-03-10 14:01:59
361
原创 Less基本使用
混合（Mixin）是一种将一组属性从一个规则集包含（或混入）到另一个规则集的方法。全局定义global.less，或者模块定义对应的less文件。为了样式统一配置，样式复用，变量命名更简单。然后混入继承border属性。首先定义一个border。全局引入或者模块引入。
2025-02-07 09:11:20
499
原创 TypeScript基础
注意，即使 tom 被声明为 Animal 类型，但因为它的值是 Horse，调用 tom.run(34) 时，它会调用 Horse 里重写的方法。在上面的例子中，我们必须在 Person 类里定义一个只读成员 name 和一个参数为 name 的构造函数，并且立刻将 name 的值赋给 this.name，这种情况经常会遇到。总结：TypeScript目前在社区中流行度越来越高，比如Vue和Angular，都是用TypeScript进行了重写，还有一些工具和基础类库也都使用了TypeScript。
2024-12-12 08:47:39
1506
原创 TypeScript开发规约思考(一)
TypeScript的受欢迎程度不言而喻，我们常用的Vue、React都在使用TypeScript开发，借助于TypeScript对面向对象和静态类型的良好支持，可以让我们的JavaScript代码编写更健壮、更可维护，适应复杂的项目。泛型在TypeScrip中应用的非常广泛，例如在做数据请求时，对于请求结果我们可以不指定类型，此时TypeScript会自动根据值的类型进行类型推断，当请求结果没有被赋值时，则会推断为any类型。我们也可以在等号两边都添加类型，当然这并没有什么意义，只会增多类型代码量。
2024-12-12 08:37:05
512
原创 前端工程化(五)项目脚手架设计与实现
目前前端项目的配置越来越复杂，项目类型也众多，不同的项目采用不同的配置导致后期管理成本和维护成本变高，并且项目结构难以统一和规范，从零开始创建项目时需要大量复制粘贴过往的项目代码，耗时耗力。让项目从创建到开发再到部署更加规范、快速和便捷，这是脚手架存在的意义。在实际的项目中，我们往往会对项目的一些基础功能做一些封装，比如统一的异常处理，统一的权限管理，国际化，常量，路由，项目结构等等。设计脚手架的基本思路是将项目模板放在git上，在创建项目时，根据不同的预设参数，下载不同的项目模板来创建项目。
2024-12-11 08:35:35
503
原创 前端工程化(四)私有npm仓库解决方案
随着项目增多，会有很多复用的业务组件或者功能，完全可以将这些封装成包进行复用，避免重复造轮子（例如脚手架等）。如果公司处于隐私保护的目的，不想将封装好的包推送到npm社区，但又需要一套完整的包管理工具来对他们进行管理，方便公司内部开发人员使用。所有有必要创建私有的npm仓库。除了直接安装使用，也可以对代码进行二次开发，license都是MIT。后端工程是nodejs实现的，前端UI工程是react。可以看到所有已发布的私有包，可以查看依赖、版本、说明、发布时间等信息。为什么需要私有npm仓库？
2024-12-10 10:35:54
1087
原创 前端工程化(三)交互规则
一款产品的成功与否，交互体验占据举足轻重的地位，就我个人认为，企业微信就是比钉钉要好用，京东app也比淘宝app要好用。在做项目中，由于交付时间的压力，更多的时候以实现功能为主，很少会考虑交互体验，然而良好的交互体验能让我们的项目更成功，反之即使我们的功能实现在完善也是毁灭性的。在第一期前端工程化的介绍中提到，要从模块化、组件化、规范化、自动化四个方面进行实践，本期内容也是规范化中的一部分。让用户了解到现在的位置，不会在产品中迷路，例如面包屑和导航可以清楚知道自己的位置。- 提供帮助信息，或者帮助文档。
2024-11-19 16:33:03
527
原创 Three.js基础概念
场景内的内容，通过相机来进行观察，相机的位置、方向、角度影响相机看到的内容，浏览器窗口则是相机的取景框，相机的角度、方向、位置可以任意调整。几何体，可以是三维的也可以是二维的，三维例如长方体、锥体、球体等，二维例如长方形、平行四边形、圆形等。简单的几何图形、点、线、面、贴图等开发可以完成，复杂的模型需要专业的人使用专业的软件制作，模型的设计也需要专业的设计人员。3D可视化、3D产品展示、数据可视化、游戏、科学教育、家装设计、Web VR等。体现在物体表面，例如常用的漫反射、镜面反射，也可以引入外部图片。
2024-11-19 16:00:54
414
原创 前端工程化(二)Webpack原理
Plugin就像是一个插入到生产线中的完整功能，在特定的时机对生产线上的资源做处理。Webpack是一个打包模块化JavaScript的工具，在Webpack的世界里，一切文件都是模块，通过Loader来转换文件，通过Plugin注入钩子，最后输出由多个模块组合成的文件，Webpack专注以构建模块化项目。在以上过程中，Webpack 会在特定的时间点广播出特定的事件，插件在监听到感兴趣的事件后会执行特定的逻辑，并且插件可以调用 Webpack 提供的 API 改变 Webpack 的运行结果。
2024-11-12 09:25:16
761
原创 Flutter基础
所以H5不能实现的功能都需要原生来做，原生代码会预先实现一些访问系统功能的API，然后暴露给WebView，以供JavaScript进行调用，WebView就成了JavaScript与原生API之前的通信桥梁，主要负责JavaScript与原生之间传递调用消息，然而消息传递必须遵守一个标准协议，它规定了消息的格式与含义，我们把这种工具称之为WebView JavaScript Bridge，简称JsBridge，它是混合开发的核心。如果想重新绘制此组件，只能重新创建此组件新的实例。
2024-11-12 09:11:52
903
原创 前端工程化(一)概述
比如目录结构的制定，合理的目录结构有助于提高项目的逻辑性和结构性，方便资源的统一管理和定位，有更好的拓展性；接口规范，这个是开发中最重要的规范，不仅涉及前端团队，也涉及后端团队，在SPA单页应用的时代，前后端分公非常清晰，协作开发的关键点就是接口；我们通常说一切皆组件，整个页面可以看成是一个大型组件，一个页面又可以按功能或者业务逻辑进一步差分成中型组件，中型组件还可以进一步拆分成小型组件，直到拆分成DOM元素为止，DOM元素可以看成浏览器的组件，也就是基础组件。怎么提高项目的开发质量？
2024-11-12 09:05:25
378
原创 微前端的浅显理解
任何技术栈都不能保证一直生命力旺盛，当我们的系统经过长时间的迭代升级，技术栈落后是不可避免的，即便都是用Vue来开发，3.x和2.x也是不兼容的，你无法在2.x的代码中使用composition api等新特性，react 15和16也面临同样的问题。微前端并非适用于所有系统，当我们系统不能推倒重做，新的需求还在源源不断的被提出，或者系统需要一套支持动态插拔的机制时，微前端是我们最好的选择。大型应用的前端工程也面临同样的问题，于是我们将微服务架构的思想运用到前端中，便有了微前端的概念。
2024-11-12 09:01:36
1967
Vue开箱即用的项目脚手架
2024-12-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人