可用：将合同数据存为json数组，用原生js动态创建表格行、绑定事件，实现模糊搜索（匹配编号/甲方）、业务逻辑排序（状态按待签署→履行中→已归档→已终止）、分批渲染（超200条用requestidlecallback），并预处理searchindex字段提升搜索性能。
怎么用 HTML + 纯前端 JS 实现可搜索、可排序的合同列表
纯 HTML 页面也能做可用的合同管理列表，关键不是“能不能”，而是“要不要承担后续维护成本”。如果你只是内部临时查合同、没权限连数据库、又不想搭后端，那就老老实实把合同数据塞进 JSON 数组，用 fetch() 或直接内联加载，再用原生 JS 渲染表格+交互。
别碰 iframe 套后台系统，也别幻想用 localStorage 存几百份合同 PDF 元数据——它上限约 5–10MB，且无索引，查个“2023 年未归档”就得遍历全部。
-
合同编号、甲方名称、乙方名称、签订日期、状态（如“履行中”“已终止”“待签署”）这 5 个字段必须作为表头显性展示，少一个都会被业务方打回来 - 搜索框默认模糊匹配
合同编号和甲方名称，不搜PDF 文件名——文件名不规范（比如 “HT-2023-001_v2_最终版.pdf”），搜了也没用 - 点击表头可按该列升/降序，但
状态列排序要按业务逻辑：待签署 → 履行中 → 已归档 → 已终止，不能按字母序排
为什么不用 table + innerHTML 拼接，而要用 document.createElement
因为你要动态更新。比如加个“标记为已归档”按钮，点一下就改状态、变背景色、重新排序——用 innerHTML += ... 会销毁整个 <tbody>，所有事件监听器全丢，分页重置，滚动位置归零。用户刚拉到第 50 条，一操作回到顶部，体验直接崩。
<ul>
<li>每行合同用 <code>document.createElement('tr') 创建，绑定 data-id="HT-2024-088" 属性，后续操作只找这个 ID，不依赖 DOM 顺序
<span class="status-tag">履行中</span>，CSS 控制颜色，JS 只改 textContent 和 className，不动结构requestIdleCallback 分批渲染，否则 Chrome 会卡顿并提示“页面未响应”本地 JSON 数据怎么组织才方便查“2024 年 Q2 签订且状态为履行中”
别存扁平数组就完事。时间字段必须是标准 ISO 格式 "2024-04-15"，别用 "2024/04/15" 或 "15-04-2024"——JS 的 new Date() 解析不可靠，sort() 会错乱。状态值统一小写英文，如 "pending"、"active"、"archived"、"terminated"，中文留作显示用，不参与逻辑判断。
[
{
"id": "HT-2024-088",
"party_a": "北京某某科技有限公司",
"party_b": "上海某某服务集团",
"signed_at": "2024-04-22",
"status": "active",
"file_path": "/contracts/HT-2024-088.pdf"
}
]
- Q2 查询 =
signed_at >= "2024-04-01" && signed_at ，字符串比较完全可行，前提是格式统一 - 加个
searchIndex字段，存预处理后的关键词串：例如"ht 2024 088 beijing keji"，全小写+去标点+空格分隔，搜索时只对它includes()，比遍历每个字段快得多 - 别在每次搜索时
filter().map().sort()链式调用——V8 会生成大量中间数组。先filter出结果集，再sort，最后render
点击合同行如何安全打开 PDF，又不暴露真实路径
直接 window.open('/contracts/HT-2024-088.pdf') 是最常见错误。路径暴露意味着别人拼 URL 就能下载全部合同；如果服务器没配 referer 限制或 token 验证，等于裸奔。
- PDF 放在非 Web 根目录下（如
/var/www/private/contracts/），Web 服务不直接映射访问 - 前端只传
id给后端代理接口，比如GET /api/contract/HT-2024-088/pdf，由后端读文件、设Content-Disposition: inline、返回流——但这已超出纯 HTML 范围 - 纯前端妥协方案：PDF 转 base64 存 JSON（仅限小合同，单文件 ≤ 200KB），用
data:application/pdf;base64,...直接window.open()，不走网络请求，也不暴露路径 - 更现实的做法：合同列表页只显示基本信息，PDF 下载/预览跳转到另一个有登录态校验的独立页面，URL 带一次性签名参数，如
/view?c=HT-2024-088&s=ab3x9f...
真正难的从来不是列表长什么样，而是谁能在没后端、没权限、没时间的情况下，让法务同事愿意每天点开这个 HTML 文件查合同——这意味着搜索必须秒出，排序不能点两次才生效，PDF 打不开时得有明确提示而不是白屏。这些细节堆起来，才是“能用”和“真好用”的分界线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
