TanStack Table V9 Beta 的重点不是增加更多表格组件，而是改变功能进入应用的方式。作为一个面向多种 JavaScript 框架的 headless UI 库，它继续把 DOM、样式和交互外观交给应用自己处理，同时通过按需启用的功能模型、基于 TanStack Store 的状态管理，以及更低的内存占用，重新整理内部架构。
对现有项目来说，这次升级不必变成一次性重写。V9 提供渐进迁移与旧版兼容路径，团队可以先验证构建体积和运行时表现，再逐步替换已有表格。
从“默认拥有全部能力”转向显式选择
V9 最值得关注的变化是 opt-in feature model，也就是由应用明确选择需要的功能。排序、筛选、分页、分组和行选择不再被视为每张表都必然需要的一整套能力。
这种设计直接影响 tree shaking。只有当功能以可静态分析的模块形式进入依赖图，打包器才有机会移除未使用代码。它也让表格配置更容易审查：开发者可以从导入和注册位置看出某个页面究竟启用了哪些能力。
例如，只读审计日志可能只需要分页和排序，而运营后台的数据表可能还需要筛选、行选择与分组。两者没有必要承担相同的代码和状态成本。
这里有一个需要注意的边界：tree shaking 并不只由库决定。应用必须使用 ESM 构建链，避免把整个命名空间作为动态对象传递，并确认打包器处于生产模式。CommonJS 转换、动态属性访问或带副作用的中间模块，都可能让未使用代码继续留在产物中。
TanStack Store 如何改变状态边界
V9 使用 TanStack Store 管理状态，目标是让状态更新、订阅和扩展机制更加一致。对于表格这种高频交互组件，这一点很重要：一次排序切换、列宽调整或行选择，不应该迫使所有无关视图重新计算。
在应用层，可以把状态分成两类：
- 表格内部状态，例如展开行、临时列宽和当前排序。
- 业务共享状态，例如 URL 查询参数、服务端筛选条件和跨页面选择结果。
迁移时不要因为底层换成 Store，就立即把全部状态提升到全局。更稳妥的方式是只提升需要持久化、共享或由服务端驱动的字段，其余状态继续留在表格实例附近。这样既能利用新的订阅模型，也不会让一个局部组件演变成全局状态中心。
扩展能力同样会受益于显式功能模型。团队自定义的权限列、统计行或领域筛选器，可以围绕清晰的状态和生命周期边界组织，而不是修改一个包含所有行为的核心配置。
用构建结果验证按需加载
Beta API 仍可能变化，因此下面不假设具体的 V9 功能导出名称，而是提供一套可以直接复制并改造的体积对比方法。先在迁移分支安装构建分析工具：
npm install --save-dev vite rollup-plugin-visualizer
在 vite.config.js 中启用报告：
import { defineConfig } from 'vite';
import { visualizer } from 'rollup-plugin-visualizer';
export default defineConfig({
plugins: [
visualizer({
filename: 'dist/bundle-report.html',
gzipSize: true,
brotliSize: true,
open: false,
}),
],
});
然后分别在迁移前后执行：
rm -rf dist
npm run build
find dist -type f -maxdepth 2 -print0 | xargs -0 du -h
打开 dist/bundle-report.html，重点检查三件事：
- 未启用的表格功能是否仍出现在依赖图中。
- TanStack Table 相关模块的 gzip 和 Brotli 体积是否下降。
- 是否有应用自己的聚合导出文件把整个库重新引入。
应用代码中的导入方式也值得检查。下面是通用示意，并非 V9 Beta 的固定 API 名称；实际功能名需要按所使用的 Beta 版本调整：
// 推荐方向：显式导入并注册当前表格需要的能力。
import { createTable } from '@tanstack/table-core';
import { sortingFeature, paginationFeature } from './table-features';
export function createAuditTable(options) {
return createTable({
...options,
features: [sortingFeature, paginationFeature],
});
}
应避免为了方便而创建一个无条件聚合所有功能的模块：
// 这种聚合方式可能削弱按需加载的收益。
export * from './sorting-feature';
export * from './filtering-feature';
export * from './grouping-feature';
export * from './selection-feature';
export * from './pagination-feature';
如果团队确实需要统一入口，可以按业务场景导出预设，例如 auditTableFeatures 和 adminTableFeatures，而不是维护一个覆盖所有页面的全功能集合。
内存优化要在真实数据规模下测量
“更低内存占用”不能只靠一个小型演示验证。表格的内存压力通常来自行模型、中间派生结果、订阅对象，以及应用自身保存的原始数据副本。测试数据至少应接近生产环境中的列数、行数和交互频率。
可以在支持相关参数的 Chromium 环境中运行下面的浏览器脚本，快速记录操作前后的堆内存。它适合作为开发阶段的趋势检查，不应替代正式的性能分析：
async function measureTableInteraction(runInteraction) {
if (!performance.memory) {
throw new Error('请在支持 performance.memory 的 Chromium 环境中运行');
}
const toMB = (bytes) => Math.round((bytes / 1024 / 1024) * 100) / 100;
const before = performance.memory.usedJSHeapSize;
await runInteraction();
await new Promise((resolve) => setTimeout(resolve, 1000));
const after = performance.memory.usedJSHeapSize;
console.table({
beforeMB: toMB(before),
afterMB: toMB(after),
deltaMB: toMB(after - before),
});
}
measureTableInteraction(async () => {
// 替换成项目中的排序、筛选、翻页或展开操作。
document.querySelector('[data-test="sort-button"]')?.click();
});
更可靠的验证方式是使用浏览器 DevTools 的 Heap Snapshot 和 Performance 面板，重复执行排序、筛选、翻页和卸载组件，观察对象数量是否持续增长。若表格卸载后仍保留大量行对象，需要进一步检查应用订阅、闭包和缓存，而不能直接归因于库本身。
渐进迁移比全面切换更适合 Beta
V9 仍处于 Beta 阶段，兼容工具的价值在于降低迁移风险，而不是让旧模式永久存在。可以优先选择一个数据规模中等、交互清晰、监控完整的页面作为试点，并记录以下基线：
- 生产构建后的 JavaScript 体积。
- 首次创建表格和首次渲染所需时间。
- 排序、筛选和分页后的响应时间。
- 重复交互及组件卸载后的堆内存变化。
- 自定义插件、服务端状态和 URL 同步行为。
试点通过后，再按功能组合迁移其他表格。对外封装层应保持薄，主要隔离 Beta API 变化，不要重新包装整个 TanStack Table，否则既会遮蔽新功能模型，也会增加未来升级成本。
TanStack Table V9 Beta 的核心价值，是让开发者更明确地控制代码、状态与内存。是否立即采用，取决于项目对 Beta 稳定性的容忍度；但即使暂不升级，也可以现在开始清理全量导入、梳理状态所有权，并建立可重复的体积与内存基准。这些工作不会因为最终版本的 API 调整而失效。