html 本身没有函数，所谓“html函数传输项目”实为javascript调用浏览器api；老旧读卡器依赖pc/sc协议，浏览器因安全限制无法直连，必须通过electron、chrome扩展或本地代理服务中转。
HTML 里根本没有“HTML 函数”这回事
这是个常见误解：HTML 是标记语言，不提供函数、逻辑或 I/O 能力。document.getElementById 是 JavaScript 的，fetch 也是；HTML 本身连读卡器的 USB 接口都看不见。所谓“用 HTML 函数传输项目”，实际是前端 JS 尝试调用浏览器 API（比如 WebUSB 或 Web Serial）与外设通信——但老旧读卡器几乎都不支持这些。
老旧读卡器通常只走 PC/SC 协议，浏览器无法直连
银行/社保类读卡器多基于 ISO 7816，依赖操作系统层的 PC/SC 服务（Windows 的 WinSCard.dll，Linux 的 pcscd）。现代浏览器出于安全限制，禁止网页直接访问串口、USB 设备或系统级智能卡服务。即使启用 WebUSB，也要求设备主动声明 WebUSB descriptor，而 2010 年前的读卡器根本没这个概念。
- 你看到的“读卡成功”页面，背后大概率是桌面程序（如 Java Applet 旧方案、Electron 封装的 Node.js 后端）在跑 PC/SC，再通过本地 HTTP 接口把结果喂给网页
-
navigator.usb.requestDevice会直接报SecurityError或返回空列表，不是代码写错了，是设备不兼容 - 试图用
XMLHttpRequest或fetch直连读卡器的 COM 口？不可能——浏览器没串口权限，OS 也不允许网页打开/dev/ttyUSB0或COM3
真要对接老旧读卡器，必须绕过浏览器沙箱
可行路径只有一条：把读卡逻辑下沉到有系统权限的进程，再让网页和它通信。这不是前端能单独解决的问题。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Electron +
node-scard：用 Node.js 调SCardEstablishContext，暴露 IPC 接口给渲染进程 - Chrome 扩展 +
nativeMessaging：写一个 C++/Go 的 native host 程序处理 PC/SC，扩展用chrome.runtime.sendNativeMessage中转 - 本地代理服务：起一个
localhost:8081的 HTTP 服务（Python Flask/Node Express），用pyscard或pcsclite读卡，网页用fetch('http://localhost:8081/read')获取结果 - 注意 Windows 上需以管理员权限运行代理或 Electron 主进程，否则
SCardConnect会返回SCARD_E_NO_SERVICE
接口速度瓶颈不在 HTML，而在协议栈和硬件握手
别被“USB 2.0 标称 480Mbps”误导。老旧读卡器的真实吞吐受三重压制：
- ISO 7816-3 的默认波特率常为 9600 或 38400，换算下来每秒仅传输几 KB 指令+响应
- PC/SC 层有固定延迟：每次
SCardTransmit调用包含建立通道、APDU 编码、错误校验、状态检查，实测单次操作常耗时 80–200ms - 若读卡器带物理按键确认（如金融 IC 卡），整个流程变成人机交互等待，JS 完全无法加速
试图用 async/await 或 Web Workers “优化”传输速度？没用——瓶颈在硬件握手和协议解析，不在 JS 执行线程。
真正卡住的地方，从来不是你怎么写 fetch，而是你有没有权限调用 SCardListReaders，以及读卡器是否还在用 2005 年的固件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
