阿丁的猫做电机驱动、逆变电源或者电池管理系统的硬件选型，大概率都有一种共同经历：需求文档里写着“额定电流 10A 以内，精度尽量高”，面前却是电流传感器型号数据库导出的几百行参数表。同一行表格里量程写法五花八门，有的是“0~5A”，有的是“±10A”，后面还跟着“300mV/A”“±0.5%”这些关键信息。早年间我习惯把型号维护在 Excel 里，靠筛选器一列一列看，数据量到两千多行以后，筛选开始卡，更麻烦的是“量程”和“排序基准”这些概念在不同人维护的表格里各有各的理解，经常出现同一款传感器两个人查询出不同结果的情况。
后来我把这套数据搬进数据库表，做成了一个“型号查询+排序输出到网页”的小系统。本文就把这套方法完整盘一遍：从字段怎么拆、建表要注意什么，到 SQL 怎么写才算符合选型逻辑，再到后端如何把查询结果安全送回网页、前端怎么实现点击表头切换排序。这套流程不挑具体语言的数据库，MySQL、PostgreSQL 或者达梦这类国产库都能按相同思路实现，非常适合做内部选型工具、替代料查找页面或者物料管理的型号列表模块。
1. 为什么要单独做一个网页查询，而不是继续用 Excel 或数据库客户端
1.1 “你会排序，不代表同事也会排序”的协作问题
只给自己一个人用的话，Excel 和数据库客户端确实都够用。Excel 筛选器点几下能出结果，数据库桌面客户端更是连 SQL 都能直接跑，功能强大得很。问题出在这是“团队工具”的场景：硬件工程师、采购工程师、质量工程师、甚至刚入职的实习生都需要查型号，不可能指望每个人都懂怎么写 SQL、维护筛选条件。
网页查询最核心的价值，是把“怎么查、怎么排序”这件事固定下来。用户在界面上输入目标电流下限和上限，选择“按精度升序”还是“按最大量程降序”，看到的永远是同一套标准化的执行逻辑。哪怕有人填了奇怪的输入，后端也要按既定规则过滤、排序、分页，不会出现“A 同事用字符串排序把 10A 排到 2A 前面，B 同事用数值排序结果不同”这种低级分歧。
1.2 网页层天然能解决权限和可见范围控制
在用桌面数据库工具直接连生产库的时候，最大的隐患是权限边界不好控制。库里存了型号参数、参考单价、供应商渠道、样品状态这些字段，选型工具只需要给用户看其中一部分。如果把整个数据库暴露给业务端，相当于把“技术选型需要用到的公开参数”和“内部成本信息”摆在了同一个平面上。
而网页后端作为中间层，可以强制指定返回哪些字段，隐藏成本字段不参与输出，甚至对不同的 URL 路径提供不同的查看范围。这样既有数据库的查询能力，又可以主动控制数据可见性，比让所有人都拿到数据库账号要稳妥得多。做内部工具时我一般就开一个只读账号，后端服务持有它，用户只跟网页对话，不直接跟数据库对话。
1.3 围绕“选型动作”设计页面，而不是围绕“数据表”设计页面
Excel 和数据表客户端里的数据是把全部字段平平地躺着放出来的，用户需要自己识别哪些列是真实的排序字段。但网页工具可以做得更贴合选型动作：用户脑子里想的是“我这边母线电流最大 5A，需要精度 1% 以内的开环霍尔”，页面就应该是两个输入框加一个排序下拉框，点击后直接给出拓扑匹配的型号。这种“需求参数驱动”的模式，比任何一张原始数据表都更适合日常选型。
所以这个系统不只是在做「数据库查询和排序输出」，它本质上是在搭建一个更友好的“选型决策入口”，而底层数据库、SQL 排序、分页技术所解决的问题，是保证这个入口在任何数据量下都能又快又准地返回结果。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 给电流传感器建表，最关键的几个字段设计决策
2.1 “量程列”必须拆开存数值，不要用“0~5A”这种字符串做筛选
我从第一版表结构里踩过的最大的坑，就是把量程原样存成字符串。当时图方便，range_text 字段写的是“0~5A”“±10A”，前端展示倒是简单，但一写 SQL 就发现没法做范围查询。想找“能测量 8A 的型号”，字符串里面根本没法可靠比较大小，除非写正则或者字符串截取，先在 MySQL 里做数据清洗再转换，性能差、写法绕，还没法用索引。
正确做法是拆成两个数值字段：current_min_A 和 current_max_A。为什么要拆成两个，而不是只存一个“额定电流”？因为传感器的量程可能不对称，比如常见的“0~5A”单极性传感器，最小是 0 最大是 5；而“±10A”那种双极性传感器，最小是 -10 最大是 10。查询的时候需要判断用户目标电流是否落在量程覆盖区间内，就必须同时保留最大值和最小值。
建表参考如下，我以 MySQL 为例，但字段思想对所有关系型数据库通用：
sql复制CREATE TABLE sensor_catalog (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
model_code VARCHAR(64) NOT NULL COMMENT '型号',
manufacturer VARCHAR(64) NULL COMMENT '厂商',
current_min_A DECIMAL(8,4) NULL COMMENT '最小可测电流(A)',
current_max_A DECIMAL(8,4) NULL COMMENT '最大可测电流(A)',
accuracy_pct DECIMAL(6,3) NULL COMMENT '精度百分比',
output_type VARCHAR(32) NULL COMMENT '输出类型',
output_sensitivity_mV_A DECIMAL(10,2) NULL COMMENT '灵敏度(mV/A)',
supply_voltage_min_V DECIMAL(5,2) NULL,
supply_voltage_max_V DECIMAL(5,2) NULL,
isolation_voltage_kV DECIMAL(6,3) NULL COMMENT '隔离耐压(kV)',
package_type VARCHAR(64) NULL COMMENT '封装形式',
temp_min_C DECIMAL(6,2) NULL,
temp_max_C DECIMAL(6,2) NULL,
stock_status ENUM('in_stock','sample','out_of_stock') DEFAULT 'sample',
unit_price DECIMAL(10,2) NULL,
data_source VARCHAR(128) NULL COMMENT '原始数据来源',
last_verified_on DATE NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
KEY idx_current_range (current_min_A, current_max_A),
KEY idx_accuracy_pct (accuracy_pct),
KEY idx_model_code (model_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='电流传感器型号目录';
2.2 保留一段“原文字段”用于展示，但别拿它做判断依据
我建议保留一个 range_note 或者直接沿用原来的 range_text，专门给前端表格展示用。比如显示成“0~5A”“±10A”这种人类熟悉的写法，比拆开后的“-10, 10”要直观得多。但排序、过滤、范围判断的 SQL 里，坚决不使用这个字段。也就是说，它只是一个“展示容器”，不是“计算字段”。这有点像是物料清单里既有“零件名称”又有“物料编号”，人工查看时用名称，系统定位时用编号，二者各司其职。
实际导入时也要注意，像“0 ~ 5A”这种带空格的数据，或者“DC±5A”这种带前缀的数据，需要先写成专门的清洗规则。我的习惯是：数据入库前做一次格式标准化，把解析出的数值部分写进数值列，清洗规则沉淀成一个脚本留着日后复查。如果从 Excel 导入的数据太乱，宁可在导入阶段报错重来，也不要放过一条脏数据进到正式表里。
2.3 冷知识：单位统一能省掉你 90% 的排序烦恼
电流传感器相关参数有很多潜在大数值陷阱：量程有的是 A，有的是 mA；灵敏度输出有的是 mV/A，有的是 V/A；供电电压可能是 3.3V、5V、12V 等等。我一开始混着存过，后来查询结果里出现了离谱排序：“100mA”和“0.1A”被当成两个完全不同的值。所以建表时要把单位锁死，用列名或注释标明，入库时统一为基准单位。
比如上面我用 current_min_A 和 current_max_A，就明确这几列的单位是安培；output_sensitivity_mV_A，单位是毫伏每安培。这样网页前端输入时用户可以自由选择 A 还是 mA，但进入后端统一换算成 A 再做查询，排序自然就是同一套标准下的数值大小比较。这个决策看着不起眼，却是整个查询排序逻辑能保持稳定的前提。
3. 写 SQL 时最容易被忽略的排序语义：数值、字符串、辅助列和分页稳定性
3.1 范围覆盖查询怎么写：不是简单地把字段 BETWEEN 两个数
先来看一个常见的需求：用户希望看到“量程能够覆盖 5A 电流”的传感器型号。很多人的第一反应是写：
sql复制WHERE current_max_A BETWEEN 5 AND 8
这是错的。这里的 BETWEEN 5 AND 8 意思是让 current_max_A 位于 5 和 8 之间，用来找“最大量程在 5A~8A 之间”的型号，这跟“量程能覆盖 5A”完全不同。
正确的“覆盖”判断，应该同时考虑最小量和最大量两个条件。一个传感器若想成功测量 5A 的电流，它的电流范围必须同时满足“最小可测值 ≤ 5A”且“最大可测值 ≥ 5A”。换成 SQL 就是：
sql复制WHERE current_min_A <= 5
AND current_max_A >= 5
如果要找“能覆盖 1A 到 10A 整个区间的型号”，逻辑会变成：
sql复制WHERE current_min_A <= 1
AND current_max_A >= 10
这就是“范围覆盖查询”和普通等值/大小比较的主要差别。很多初做选型工具的人，对这一层逻辑没理清，查出来的型号要么漏掉 ±5A 的，要么混进最大量程不到 5A 的。只有把“选型目标电流”转换成对 min/max 两个字段的不等式组，才能表达完整的覆盖语义。
3.2 为什么“字符串排序”和“数值排序”是两条路，不能混着用
标题里说的“排序”，放到数据库里往往不是一套逻辑走天下。同一个 model_code 列，如果按字符串排序，会按字典顺序排：HM-10A、HM-2A、HM-20A、HM-30A，这在字典序里是合理的，因为字符串比较是从左到右逐字符比较的，所以 “10” 排“2”前面不奇怪。
但如果用户想按“量程大小”排序，那必须使用数值列 current_max_A 排序。举一个例子，下面这批型号：
| 型号 | current_min_A | current_max_A | range_text |
|---|---|---|---|
| HM-S05 | 0 | 5 | 0~5A |
| HM-S20 | 0 | 20 | 0~20A |
| HM-S100 | 0 | 100 | 0~100A |
| CYH-210 | -10 | 10 | ±10A |
| CYH-225 | -25 | 25 | ±25A |
如果人工在网页里按表头“最大量程”点击升序，用户心理预期是 5A、10A、20A、25A、100A，也就是按 current_max_A 从 5 升到 100。但如果后端不小心写了 ORDER BY range_text，结果很可能会按字典序排出 0~100A、0~20A、0~5A、±10A、±25A 这种“看着整齐但完全不符合量级逻辑”的顺序。这类混淆是最隐蔽的陷阱，尤其在返回值同时包含了展示字段和排序字段时。
从技术上规避只有一个办法：排序字段必须指向后端字段白名单里定义了数值类型或日期类型的列，比如 current_max_A、accuracy_pct、unit_price、last_verified_on，而不允许直接接收前端传过来的任意字符串，再把这个字符串拼进 ORDER BY。
3.3 排序稳定性：所有排序结果必须有一个“锚点”列
另一个容易发生的问题，是数据库明明用了 ORDER BY，但翻页后数据还是重复或漏行。常见原因在于，排序依据不够“唯一”。比如页面每次只按 current_max_A 排序，而数据库里有很多型号的 current_max_A 都是 10A，当数据量增加、更新或索引执行计划变化时，这部分同值记录的顺序就可能不稳定。第一页返回了 ID=3 的记录，第二次请求第一页时因为同值块内部顺序变了，变成返回 ID=4，而第二页又把 ID=3 带出来了，用户看起来就像数据“串行”了。
解决方案是给排序规则加一个次关键字，通常选主键或唯一型号编码作为锚点：
sql复制ORDER BY current_max_A ASC, model_code ASC
这句话表达的含义是：先按最大量程从低到高排，满足同一最大量程的记录，再按型号编码排序。因为 model_code 应该是唯一的，所以整套排序结果变得确定。加上排序锚点之后，分页查询（比如 LIMIT 20 OFFSET 40）就可以稳定地从“第 3 页”请求到和第 1 页、第 2 页完全不重叠的后缀记录。
还有一个和分页查询有关的问题：LIMIT ? OFFSET ? 越到后面越慢。数据量几千行时无所谓，如果未来到了几十万行传感器记录或者日志型数据，就需要换 keyset 分页（WHERE cursor > last_value ORDER BY cursor LIMIT 20）。对于单纯的电流传感器型号表，几千到几万行通常不会到性能瓶颈，主键锚点加 LIMIT 偏移已经够用。
4. 后端接口：不能直接暴露数据库，而要做参数通道和数据守门员
4.1 网页直连数据库最大的问题不是性能，而是安全和边界
有一种看似偷懒的方案是“网页直接连 MySQL”，比如在后台代码里硬编码数据库账号，然后用服务器端语言直接跑查询。不要这样干。数据库连接串一旦被打包进前端资源，或者在服务端日志里泄露，攻击者就能拿这个连接去拖库、改数据、删除记录。哪怕只是内部系统，也不该把整个表结构暴露给任何可被浏览器触达的通道。
所以我的做法是网页和后端之间只走一个 HTTP API，后端再持有一个只读权限的数据库账号去查库。所有网页传过来的查询参数，都只当作“输入”，后端要重新校验、映射、拼装成安全的参数化 SQL。这样做有几个明显收益：
- 数据库的账号、密码、连接地址不会出现在浏览器网络请求里。
- 后端可以统一设超时时间、行数上限、日志记录，防止某个同事误传了一个
page_size=999999把服务拖垮。 - 隐藏不重要或敏感的字段，只返回前段需要的列。
4.2 设计查询接口的参数体系：把选型条件显式化
我给这个查询工具设计的接口长这样：
code复制GET /api/sensors
参数：
keyword 型号或厂家关键字，可选
min_current_A 目标电流下限(A)，可选
max_current_A 目标电流上限(A)，可选
sort 排序字段，可选，默认 current_max_A
order 升序还是降序，可选，默认 asc
page 页码，默认 1
page_size 每页条数，默认 20，最大 50
为什么要显式用 min_current_A 和 max_current_A，而不是并成一个范围字符串？因为范围逻辑需要前端先拆分，后端才能把它翻译成 current_max_A >= ? 和 current_min_A <= ? 这两组条件。如果前端只传 range=5A~10A，虽然看着参数少，但后端要解析字符串，增加解析歧义（比如“±10A”用这个格式你就没法传负值）。所以宁可多传两个量化参数。
响应消息建议统一成下面这种结构，给 Code、Message、Data 都留好位置：
json复制{
"code": 0,
"message": "ok",
"data": {
"total": 187,
"page": 1,
"page_size": 20,
"items": [
{
"model_code": "HM-S10",
"manufacturer": "example",
"range_text": "0~10A",
"current_min_A": 0,
"current_max_A": 10,
"accuracy_pct": 0.5,
"output_type": "analog",
"stock_status": "in_stock"
}
]
}
}
total 是查询结果总数，用于前端显示“共 187 条，第 1/10 页”。page 和 page_size 则配合前端的分页控件使用。返回这种结构以后，前端就不需要自己去猜数据库总行数，也不需要维护内部状态里的排序值，一切以请求参数为准。
4.3 用“字段白名单”防御 ORDER BY 注入，光靠参数化不够
做查询接口时，有一个容易被忽略的安全点：参数化查询确实能挡住大部分 WHERE 条件注入，但对 ORDER BY 这种没法直接用占位符绑定列名的位置，很多人会图省事，直接拼 SQL：
sql复制ORDER BY {sort_field} {order_dir}
如果网页把 sort 参数透传过来，攻击者就可能传 current_max_A; DROP TABLE ...，或者利用报错信息反推表结构。防御手段不是靠黑名单过滤，而是用白名单映射：
py复制# 伪代码示例，映射可排序字段
sortable = {
"model_code": "model_code",
"current_min": "current_min_A",
"current_max": "current_max_A",
"accuracy": "accuracy_pct",
"price": "unit_price",
"updated": "last_verified_on",
}
if sort not in sortable:
sort = "current_max_A"
order_dir = "ASC" if order == "asc" else "DESC"
这样用户传进来的 order_dir 只有“asc”或“desc”两个选择，传进来的 sort 只能从预设映射表里取键。就算请求里带了其他值，后端完全无视它。排序字段不像普通的字符串匹配，它本质上代表“数据库表的某一列”，这个决策不能交给客户端任意指定。
接着用参数化查询把过滤条件绑定进去。以 Python 风格示例写核心逻辑：
py复制sql = """
SELECT model_code, manufacturer, range_text,
current_min_A, current_max_A,
accuracy_pct, output_type, stock_status
FROM sensor_catalog
WHERE current_min_A <= :target_max
AND current_max_A >= :target_min
AND (model_code LIKE :kw OR manufacturer LIKE :kw)
ORDER BY {sort_col} {sort_dir}, model_code ASC
LIMIT :limit OFFSET :offset
"""
params = {
"target_min": 1,
"target_max": 10,
"kw": "%HM%",
"limit": 20,
"offset": 0,
"sort_col": sortable[sort], # 来自白名单
"sort_dir": order_dir, # 仅 ASC/DESC
}
用这种方式传参，即使数据库账号本身有删表权限，从网页上传进来的请求也无法穿越到白名单之外。
5. 把排序结果输出到网页：表格渲染和“点表头排序”的两条实现路线
5.1 路线一：服务端渲染，模板输出 HTML 表格
如果项目比较小，只有十几个人用，倒也不必搞前后端分离。后端在收到查询请求后，直接查询数据库，把结果塞进一个模板文件，服务端渲染出完整 HTML 表格。这种方式的优点是浏览器地址栏里可以直接带查询参数，比如：
code复制/sensors?min_current_A=1&max_current_A=10&sort=current_max&order=asc&page=1
把页码和排序状态放在 URL 参数里有一个天然好处：可以加书签、可以直接复制给同事。刷新页面也不会丢失查询状态。缺点则是整体交互偏“传统”，每次点击排序都会重新加载页面，请求延迟一般几百毫秒，对内部工具来说完全能接受。
5.2 路线二：后端只返回 JSON，前端异步渲染表格
如果希望交互更顺滑，不希望每次点表头都白屏重载，那就走异步 JSON。前端用一个简单的渲染循环，把 items 数组填充到 <table> 里；点击表头时触发一个 loadData() 函数，带上新的 sort 参数向后端请求。因为排序结果最终由服务端 SQL 决定，前端最多负责“发起请求、解析数据、渲染结果”，不承担核心排序逻辑。
一个效果不错的做法是点击表头时自动切换升序/降序。首次点击默认升序，再点同列表头切换为降序，同时在表头图标上标一个箭头表示当前生效的排序方向。这里需要注意，切换排序后页码要重置到第 1 页，否则用户从第 5 页点击排序，看到的列表只是第 5 页数据的新排序，体感会非常奇怪。
5.3 请求竞态问题：用户点太快时，别让旧请求覆盖新请求
用异步请求渲染后，如果用户快速点击了几个不同的表头排序，网络响应可能乱序回来：最后发出的请求反而先返回，先发出的请求可能因为网络阻塞晚回来，最终覆盖掉新的排序结果。这个问题叫“请求竞态”，在前后端分离页面里很常见。
我的处理方案很简单：设置一个请求序号。比如在表格实例里定义一个 let requestSeq = 0;，每次发起请求时先 requestSeq++; 然后把当前序号存到局部变量 const seq = requestSeq;，在响应回来时检查 if (seq !== requestSeq) return; 如果不是最新请求就直接丢弃。用这种防旧响应干扰的手段，基本能解决快速点击导致的排序回退错乱。
js复制async function loadSensorList(params) {
const seq = ++loadSensorList.seq || 1;
const qs = new URLSearchParams(params).toString();
const res = await fetch(`/api/sensors?${qs}`);
const json = await res.json();
if (seq !== loadSensorList.seq) return; // 丢弃过期响应
renderTable(json.data.items);
renderPager(json.data.total, json.data.page, json.data.page_size);
}
5.4 前端要不要“二次排序”？我的结论是别做
有的人看到“排序输出到网页”，第一反应是前端加载全部数据后，用某个排序函数直接对表格做前端排序。比如把整个表搬到浏览器里，再用 JavaScript 的 sort() 函数去排。如果总行数只有几百，这没有问题；但如果是 5000 行、10000 行，一次性全量加载会导致首屏很长，而且前端排序和数据库后端排序很可能包含两套不同类型转换逻辑，容易产生“看似一致实际不一致”的结果。
真正的工程项目里，我更倾向于后端排序。让数据库承担排序，是因为数据库里的列类型、索引、collation 都是可控的，SQL 的 ORDER BY 可以直接利用数据类型做正确的比较；前端拿到数据以后就只负责展示，渲染多少行就接受多少行。这个职责划分清晰了，系统出问题的概率会低很多。
6. 实测复盘：排序逻辑对了但结果仍然可疑？问题常出在这些细节上
6.1 前端输入的数据单位，后端有没有统一换算？
我遇到过最典型的现象是：网页上明明输入了 1A~10A，查出来却漏掉了 0~1A 这款型号。后来排查发现前端把用户输入的单位当成了 mA，提交给后端却传了 1A 的数值。例如用户选了 mA，那么输入 1000 应该换算成 1A，代码写错成 1000A，自然没有任何一款传感器的量程能覆盖。
所以，接口层的约定必须用注释和文档写明白：无论用户界面怎么选单位，后端接口只接受以 A 为单位的 min_current_A 和 max_current_A。前端提交之前必须做换算，后端也要在入口处做一次 if max_current_A > 10000: 之类的合理性检查，把异常阈值尽早拦截。排序正确的前提是数字本身没有发生量级漂移，这个检查值得写在接入文档第一行。
6.2 数据导入时，把“展示文本”和“数值字段”分开校验
在整理几份传感器规格表后，我发现不少供应商提供的参数里有“工作电压 DC 3.3~5V”“静态输出 2.5±0.05V”“响应时间 1μs”这些字段，量纲复杂。如果整段塞进同一个 VARCHAR 字段，排序无从谈起。但拆列后导入又很容易出现“半结构化”错误，比如某一行 current_max_A 存成了 10A，MySQL 遇到字符串时会把它转成 10，却不会报错；另一行存了 10 A 中间带空格，可能导致转换异常或被当成 NULL。
我的校验经验是：导入后立即做一次“数值健康检查”。跑一句 SQL，把量程最小值大于最大值、数值列为空但展示文本非空、精度字段超过合理范围等异常行直接拉出来：
sql复制SELECT model_code, range_text,
current_min_A, current_max_A
FROM sensor_catalog
WHERE current_min_A > current_max_A
OR (current_min_A IS NULL AND range_text IS NOT NULL)
OR current_max_A <= 0
ORDER BY model_code;
这类查询结果应该是 0 行；如果还有脏数据，就说明上游 Excel 的清洗规则还没覆盖所有写法。修复完成后再上线给网页端用，能避免用户看到“倒挂量程”甚至负数最大量程这种尴尬结果。
6.3 排序锚点和分页索引是否一致？
在前边说排序加 model_code 作为次关键字时，其实还有一层隐含要求：分页查询要想稳定，数据库执行计划最好能一直走同一个索引。比如用 ORDER BY current_max_A ASC, model_code ASC 这种方式排序时，MySQL 会选择 idx_current_range 或临时排序。数据量较小可能没感觉，但为了稳妥，可以在语句后加 EXPLAIN 看一下执行计划，确认没有出现 filesort 导致的大量磁盘临时表操作。
如果前端经常按多个不同字段切换排序，像 accuracy_pct、unit_price，数据库不太可能为每一种排序都建一个索引。这时只要行数不大，临时排序的开销通常可以接受。等数据量真的变大之后，再去考虑针对热点排序字段建联合索引，尽量避免没做完性能优化就强行堆功能的现象。
6.4 用“边界值”验证排序输出，不要只测中间值
给这个功能收尾时，我还习惯看两组非常简单的边界数据：双极性传感器（current_min_A 为负数）和量程下限正好为 0 的单极性传感器。因为很多 Web 表格组件把“0”当空值、把“-10”当小于号处理，前端可能把它显示成“-10.0000”这种不友好的形式。为了稳妥，建议在输出接口里直接提供 range_text 这样的展示字段，让前端尽量别对数值列做拼接处理。排序用数值列，展示用文本列，两者职责明确。
比如前端渲染量程时直接使用 range_text，就不会出现“-10 到 10 要自己拼成 ±10A”这种逻辑。用户看到“±10A”的一瞬间，才真正明白系统输出的排序结果是在对“一个实际存在的传感器型号页面”做排序，而不是在排一堆脱离物理意义的数字。
写在最后：把型号数据从文档里搬到网页上，这只是第一步
从梳理字段、建表导入，到写出接口和网页排序，整个过程最让我觉得值得的并不是最后那个点击表头就能升降序的表格，而是中间理顺“不同人对电流传感器量程的理解”的过程。材料领域的数据管理，最怕的就是把 Excel 里能看的东西原封不动搬到网页上，却不体现代码里具体的取舍和判断逻辑。数据库查询和网页输出只是载体，真正迭代的是数据本身的规范化程度。
如果你正打算做类似的小工具，我的建议顺序是：先把字段结构设计好，把数值列和展示列区分开；再单独写一个导入清洗脚本，每天或者每次收到新表后跑一遍；然后才写后端 API 和前端界面。等网页版跑起来以后，再慢慢加入按精度、按输出类型、按封装形式的多条件排序，给选型同事开放权限，这些功能自然就长出来了。