从单文件到可扩展:我给 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 ...
