从单文件到可扩展：我给 stock-sdk 做的一次架构升级
这篇文章不是一份“正式的技术方案文档”，而是站在工具作者的视角，记录我在给 stock-sdk 做一次比较大的架构升级时，真实的思考过程、取舍以及落地方案。 如果你也维护过一个“越写越大的 SDK / 工具库”，大概率会在下面的某些场景里看到自己的影子。 背景：当一个 SDK 开始“失控”在很长一段时间里，stock-sdk 的代码结构其实非常简单： 一个 sdk.ts 一些工具函数 一份类型定义 这样写在早期非常爽： 新功能直接往里加 一个文件就能看到所有逻辑 调试也很直观 但问题在于，它会一直长。 当 sdk.ts 的体量来到一千多行之后，一些信号开始变得明显： 找一个方法要不停地滚动 改一个功能，总担心影响到旁边完全不相关的逻辑 测试文件也跟着一起膨胀 心理上开始抗拒“再往这里加东西” 这不是某一行代码的问题，而是结构已经不再适合继续演进。 我给这次重构定下的几个底线在真正动手之前，我先给自己划了几条“红线”，否则很容易越改越乱： 对外 API 必须完全兼容（这是 SDK，不是业务项目） 可以慢慢迁，但不能一次性推翻重来 结构要能撑得住未来继...
stock-sdk：为前端设计的股票行情 SDK
做过金融相关的前端（哪怕只是行情看板 Demo），大概率都会遇到一些工程层面的麻烦： 股票行情工具大多集中在 Python 生态，前端难以直接使用 为了拉数据，不得不自建一层后端中转 接口格式混乱、字段不友好，还要处理 GBK 编码 全市场批量拉取时，并发、限频、容错一堆细节要自己兜 stock-sdk 做的事很朴素：把这些公开数据源的“工程脏活”封装起来，提供一个 零依赖、TypeScript 友好、浏览器与 Node.js 都能用 的行情 SDK，让前端可以像调用普通 API 一样获取行情、K 线和分时数据。 一、stock-sdk 是什么？解决了什么问题先说结论：stock-sdk 是一个为浏览器与 Node.js 设计的股票行情 SDK，支持 A 股 / 港股 / 美股 / 公募基金的实时行情与常用 K 线数据，并提供全市场批量拉取能力。 它主要针对的是“前端直连数据源”时常见的工程问题： 数据源接口陈旧：字段不友好、格式与分隔符不统一，需要自己拼参数、拆字段。 编码处理分散：不少接口返回 GBK，如果在业务代码里处理，很容易遗漏或...
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，可以在网页上开...
前端如何进行权限设计
权限设计最常见的翻车姿势有两种： 前端只做“菜单隐藏”，接口没做鉴权（安全漏洞） 后端鉴权做了，但前端没有体验层的控制（用户到处撞 403） 这篇就按“模型 → 同步 → 前端落点 → 后端兜底”的顺序，把常见实现拆开说：路由守卫、按钮/组件权限、动态路由、接口权限控制，各自适合解决什么问题。 一、先立模型：资源、动作与主体 主体（Subject）：用户、角色、组织、租户等。 资源（Resource）：页面、菜单、按钮、接口、文件等。 动作（Action）：view/create/update/delete/export… 常见模型： RBAC：角色-权限映射，简单高效；粒度通常到菜单/按钮/接口。 ABAC：基于属性的策略更灵活（时间段、地理、部门级别等），实现与维护更复杂。 建议以 RBAC 起步，保留扩展位点（在权限项中附带资源/动作/条件）。前端更多负责“展示与导航层过滤”，真正的安全边界一定在后端（别指望前端挡住恶意请求）。 二、路由权限控制（Route Guar...
前端可视化技术 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...
基于 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 ...
