Streamlit 开发者的状态同步组件库

Streamlit 开发者在用 st.data_editor 结合 session state 时，输入数据会“消失”，同样的内容要输入两次才能生效：“Basically the state of data_editor is always one loop behind in updating, and the input seems to dissapear until another change is made.”。同时 Streamlit 的运行模型是“任何 widget 交互都重跑整个脚本”，开发者只能用 forms、caching 等绕路方案，希望有 rerun=false 这类控制能力。这是框架级缺陷带来的反复调试和体验问题，不是用户自己的业务问题。

用 Streamlit 快速搭建数据应用/内部工具的开发者和数据科学家。市场规模取决于 Streamlit 生态的活跃度（其 GitHub issue 单条即有 12–22 条评论参与），属于开发者工具里的细分利基，量级中等偏小。

做一个 Streamlit 状态同步扩展库（Python 包），核心功能：st.data_editor 包装组件——自动处理与 session_state 的双向绑定，消除“输入消失、状态慢一拍”的缺陷；rerun 控制 API——让开发者对单个 widget 声明 no-rerun 或 debounce，避免整页重跑；声明式状态层——以响应式变量的方式读写应用状态，屏蔽 Streamlit 的脚本重跑模型；迁移辅助——提供从原生 st.data_editor + session_state 写法到包装库的一键改写（静态分析 + 自动代码转换）。AI 在其中主要承担自动代码迁移和社区 issue 模式的检索解释。

第一版只做一件事：提供一个 st.data_editor 的替代包装函数（如 st_synced_data_editor），内部处理好与 session_state 的双向同步，保证输入不丢失、状态不滞后；附带一个 rerun 控制 helper，让指定 widget 交互不触发整页重跑。明确不做：多页面状态共享、其他 widget 的状态管理、与 Streamlit 之外的框架集成。

平台依赖是最大风险：问题根源在 Streamlit 框架本身，官方随时可能在上游修复（issue 已有官方仓库回应），届时产品价值归零；开源开发者工具变现路径不清晰；需要持续跟进 Streamlit 版本升级维护兼容性；GitHub 上的抱怨热度（12–22 条评论）不代表足够多的开发者愿意为解决方案付费。