WebGL 基础入门篇
本篇侧重 WebGL 基础，默认你是“没写过/刚入门”的状态。 文章里会穿插一些小 demo（我更喜欢边跑边理解，而不是只看概念）。 会涉及少量矩阵/坐标的推导，不想深究也没关系，先把流程和 API 跑通就已经很够用了。 简介WebGL 是什么WebGL，全称 Web Graphics Library，是一种用于在网页浏览器中渲染 2D 和 3D 图形的 API。它基于 OpenGL ES 2.0，通过 JavaScript 在不使用插件的情况下，直接利用 GPU 进行硬件加速渲染。 WebGL 是现代浏览器（如 Chrome、Firefox、Safari）支持的标准，能够在 PC、手机等多平台上运行。 WebGL 的应用场景游戏开发：许多浏览器游戏通过 WebGL 实现复杂的 3D 场景和交互效果。 图形/游戏引擎 数据可视化：使用 WebGL 可以在网页上实现高性能的 3D 数据可视化工具。 交互式 3D 网页：可以实现像 3D 地图、虚拟展览等内容。百度地图 VR/AR：结合 WebGL 和 WebXR API，可以在网页上开...
前端可视化技术 Canvas vs SVG
做可视化时经常会卡在第一个问题：到底用 Canvas 还是 SVG？ 我的经验是：别从“哪个更高级”开始比，先从你的需求开始问——图形数量多不多？交互复杂不复杂？需不需要无损缩放？要不要 DOM 事件和 CSS 控制？ 下面就按这些问题，把 Canvas/SVG 的差异掰开揉碎聊一遍。 一、技术原理与渲染方式Canvas：位图渲染 原理：基于像素的位图渲染，通过 JavaScript API 在 2D 上下文上绘制图形。 渲染流程：CPU 计算 → GPU 光栅化 → 像素填充 → 屏幕显示。 特点：一次性绘制，绘制完成后图形失去”对象”属性，无法单独操作。 12345678910111213// Canvas 绘制示例const canvas = document.getElementById('canvas');const ctx = canvas.getContext('2d');// 绘制矩形ctx.fillStyle = '#ff6b6b';ctx.fillRect(10, 10, 100, 5...
前端如何进行权限设计
权限设计最常见的翻车姿势有两种： 前端只做“菜单隐藏”，接口没做鉴权（安全漏洞） 后端鉴权做了，但前端没有体验层的控制（用户到处撞 403） 这篇就按“模型 → 同步 → 前端落点 → 后端兜底”的顺序，把常见实现拆开说：路由守卫、按钮/组件权限、动态路由、接口权限控制，各自适合解决什么问题。 一、先立模型：资源、动作与主体 主体（Subject）：用户、角色、组织、租户等。 资源（Resource）：页面、菜单、按钮、接口、文件等。 动作（Action）：view/create/update/delete/export… 常见模型： RBAC：角色-权限映射，简单高效；粒度通常到菜单/按钮/接口。 ABAC：基于属性的策略更灵活（时间段、地理、部门级别等），实现与维护更复杂。 建议以 RBAC 起步，保留扩展位点（在权限项中附带资源/动作/条件）。前端更多负责“展示与导航层过滤”，真正的安全边界一定在后端（别指望前端挡住恶意请求）。 二、路由权限控制（Route Guar...
ESLint 代码检查的过程是啥？
你有没有遇到过这种场景：CI 上 ESLint 跑了 5 分钟，最后报了一个“no-unused-vars”，你一脸问号：就这？ ESLint 其实干的活比你想的多：找文件、读配置、解析代码、建 AST、跑规则、收集问题、还能顺手给你修一部分。它慢，很多时候不是“它摆烂”，而是“它真在干活”。 一句话版本：ESLint 在做什么？把 ESLint 想象成“代码体检”就行： 把源代码变成 AST（抽象语法树） 用一堆规则（rules）去遍历 AST，找到问题 输出诊断结果（可选：自动修复一部分） 你看到的每一条报错，本质上就是：“在某个 AST 节点上，这条规则觉得你写得不对。” ESLint 的完整流水线（从命令到报错）先上一个总览流程图，后面逐段拆开。 flowchart TD A[eslint CLI / IDE] --> B[解析参数与工作目录] B --> C[加载配置<br/>flat config 或 eslintrc] C --> D[构建规则集/插件/...
基于 Rust 的代码 Lint 方案 - Oxlint
一、Oxlint 简介官网：https://oxc-project.github.io/ Oxc (The Oxidation Compiler) 是一套用 Rust 写的 JS/TS 工具链：parser、linter、formatter、transpiler、minifier……目标就是“把前端工程里那些很耗时的工具”用更快的实现替掉一部分。 Oxlint 可以把它理解成“更快的 ESLint（但不是完全替代）”：它会检查常见错误/陷阱/不规范写法，并输出诊断信息。最大的卖点不是“规则更严”，而是速度——特别适合放在 lint-staged/CI 的前置检查里，先把最常见的问题快速挡掉。 二、特性1. 性能官方宣称速度比 ESLint 快 50-100 倍，并且可以更好地利用多核。下图为 Oxlint 与 ESLint 耗费时间对比： 尤雨溪在试用之后都在感叹 Oxlint 的速度之快。 2. 开箱即用零配置Oxlint 默认规则集更偏“正确性”和“明显的坑”（语法错误、冗余代码、容易误解的写法），而不是那种“风格洁癖”或“团...
从 React 层面能做的性能优化有哪些？
很多时候“React 很慢”其实是“某几个组件在不停做没必要的事”：重复计算、反复渲染、列表一次性渲染太多、Context 一更新全家跟着跑……这篇文章不聊 Web 性能的全套（资源、网络、缓存那些），只聚焦在 React 使用层面：我平时会优先排查什么、哪些招数用起来确实顺手、以及常见的反作用。 一、组件渲染优化先说一个我自己的习惯：别一上来就“优化”，先确认“慢”到底慢在哪。多数情况下你会发现问题不是渲染次数多，而是某次渲染里做了太多工作（比如列表的排序/过滤、复杂的图表计算、或者一堆组件因为 props 引用不稳定被带着刷新）。 1. React.memo - 避免不必要的重渲染React.memo 的核心作用不是“让组件变快”，而是“当 props 没变时，别再渲染一遍”。它适合那种渲染成本比较高、同时 props 又比较稳定的子组件（尤其是列表 item / 图表 / 大块 UI）。 但也别把它当银弹：如果你每次都传进来一个新对象/新数组/新函数（比如 style={{...}}...
JS超过Number最大值的数怎么处理?
前端最容易踩的大数坑通常有两类： 金额、计数、ID 这类“看起来是整数”的东西，一旦超过 2^53 - 1（Number.MAX_SAFE_INTEGER），就会开始丢精度； 真的特别大的浮点数，超过 Number.MAX_VALUE 直接变成 Infinity。 原因也很简单：JavaScript 的 Number 用的是 IEEE 754 双精度浮点。它能表示很大的范围，但整数精度只有 53 位。 超出 Number.MAX_VALUE：超出此值的数值会变为 Infinity。 超过安全整数范围：大于 Number.MAX_SAFE_INTEGER 的整数可能会失去精度。 遇到这些问题时，别急着“找一个库来解决”。先想清楚：你要处理的是“大整数”、还是“高精度小数”（比如金融）？两者方案不一样。 使用 BigIntES2020 引入了 BigInt，用来表示任意大小的整数。它的心智模型也很直接：只要是整数，就不会丢精度。 123// 创建一个超过 Number.MAX_SAFE_INTEGER 的整数const bigIntValue = 900719925474...
前端页面性能优化应该从哪些方向来思考?
页面性能优化最容易走偏的一点是：一上来就“上手段”（压缩、上 CDN、拆包），但没有度量闭环。我的习惯是先把指标跑起来（本地 + 线上），再按问题类型逐个拆解：体积、网络、渲染路径、主线程、用户感知，最后再用工程化把基线守住。 一、先谈“怎么量”——关键指标 Core Web Vitals： LCP（Largest Contentful Paint）：最大内容绘制时间，衡量首屏主要内容何时可见。 INP（Interaction to Next Paint）：交互到下一帧的时延，替代 FID 评估交互响应性。 CLS（Cumulative Layout Shift）：累积布局偏移，衡量页面稳定性。 其他常用指标：TTFB、FCP、TTI、TBT、FP/FMP、JS long task 数量等。 小建议：本地 Lighthouse 先摸个底，线上用 RUM（真实用户监控）看真实分布，最好再按设备/网络分层，不然平均值很容易骗你。 二、资源体积优化（越少越好）1. JavaScript：减少、拆分、可缓存 Tree Shaking / Dead ...
何为 Babel Runtime？
第一次在依赖树里看到 babel-runtime/@babel/runtime，很多人会下意识以为它是“又一个 polyfill 包”。但它更像是一套“编译时生成代码的公共工具箱”：把那些会重复出现在每个文件里的 helper 抽出来复用，减少产物体积；同时也能在需要时避免直接往全局对象上打补丁。 什么是 Babel Runtime？Babel Runtime 可以理解成 Babel 的“运行时配套包”，主要做两件事： 复用 helper：比如 class 继承、对象展开、async/await 的一些辅助逻辑。如果每个文件都内联一份 helper，bundle 里会出现大量重复代码。 （可选）避免全局污染：有些能力如果靠 polyfill，会往全局（比如 Promise、Array.prototype）上“补方法”。做业务项目通常问题不大，但写 SDK/组件库时就很容易和别人的环境打架。 通常它会和 transform runtime 插件一起用：编译阶段把“内联 helper”替换成“从 runtime 包里 import”。 说明：Babel ...
如何判断 DOM 元素是否在可视区域？
“怎么判断一个元素在不在可视区域？”这个问题很像“怎么判断你老板在不在工位？”——你当然可以一直探头看（scroll 事件里狂算），但你也可以请前台帮你盯着（IntersectionObserver）。 区别就是：前者你累、页面也累；后者你轻松，浏览器也更愿意配合。 先把需求说清楚：你到底要判断哪一种“可见”？很多 bug 的根源不是 API，用错了，而是你们根本没对齐“可见”的定义。常见有三种： 露个头就算可见：元素只要和视口有交集就算（曝光埋点经常这么干）。 至少可见一半：比如图片懒加载、卡片动画，想更“稳”一点。 完全可见：通常用于“必须完整展示后才算到达”的场景。 后面所有方案，都能支持这三种，只是配置/判断方式不同。 推荐方案：IntersectionObserver（省心 + 省电）如果你能用 IntersectionObserver，就优先用它。 它不是让你在滚动时疯狂算，而是浏览器在合适的时机告诉你：现在它交不交叉、交叉比例是多少。 1) 最小可用示例：露头就算12345678910111213141516171819202122functio...
