我用 stock-sdk 做了一个纯前端的 A 股看板
先交代一下背景：我平时看盘有个“坏习惯”——开一堆 APP/网页，然后在它们之间疯狂切换，最后得到的不是信息，而是焦虑。 所以干脆自己写一个：打开一个页面，把常用的行情、板块、分时、K 线、资金面、筛选工具都塞进去。 这个项目就是 stock-dashboard：React + TypeScript + Vite 的前端看板。数据源全部来自 stock-sdk，没有后端、没有 Python 定时脚本，就是纯前端直接拉数据。 体验地址我直接放这： stock-dashboard （如果你也想摸鱼，记得开小窗）。 先说最关键的：数据层怎么接的？项目里我把 stock-sdk 的调用统一收口到了 src/services/sdk.ts。 这里做了三件很“工程化但不装”的事： SDK 单例 + 重试new StockSDK({ timeout, retry })，网络抖一下、接口偶发超时这种事就交给 SDK 自己兜底（最多重试 3 次，指数退避那套）。 内存缓存（TTL）行业/概念列表这种 10 秒内不会突然“宇宙大爆炸”的数据，缓存一...
我写了个“能少写点代码”的汇率 SDK：Exchange Rate SDK
如果你做过电商、出海、旅行、订阅制产品，或者任何“用户可能会拿着不同货币来烦你”的业务，你大概率经历过这种对话： 产品/老板：这个页面加个汇率换算吧，很简单的。你：行啊。（内心：又来了） 因为“很简单”的背后通常是： 选个汇率接口（最好不要 key，不要注册，不要配额，不要收费……懂的都懂） 处理超时、网络抖动、429/5xx（不然线上会让你看到人间真实） 缓存（不然你会被同事/自己/用户一起打爆） 货币列表（最好还能搜中文，不然“人民币”三个字能让你写一整套映射） 最后再把这些东西重复粘贴到下一个项目里，继续假装这叫“沉淀” 于是我写了 exchange-rate-sdk：一个轻量级、跨平台（浏览器 + Node.js）的汇率查询 SDK。它的目标就一个：把这些“每个项目都要做一遍、又不想做一遍”的活儿，打包成一个你能直接用的工具。 如果你只想先试试水，直接去 Playground：https://chengzuopeng.github.io/exchange-rate-sdk/ 顺手把链接也放这儿（方便你收藏/转发&#...
从单文件到可扩展：我给 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 线和分时数据。 前阵子有个朋友问我：抓股票行情数据是不是必须学 Python？ 我说不一定啊，JavaScript 也能搞。 他不信，说你随便找个能用的 JS 股票数据库试试？ 我还真试了。然后发现……他说得对，真没几个能用的。 被迫营业事情是这样的。 我本来只是想给自己做个小工具，每天早上打开浏览器就能看到自选股涨跌的那种。功能很简单，就是个看板页面，技术上也没什么难度。 难的是数据从哪来。 找了一圈才发现，股票数据这块，Python 生态是真的强。AkShare、Tusha...
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...
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={{...}}...
