![[新人]记录一次从Streamlit到Vue技术过渡的浅探](/imgrand/rGOrEuL4.webp)
[新人]记录一次从Streamlit到Vue技术过渡的浅探
- 内容介绍
- 文章标签
- 相关推荐
image1290×920 126 KB
这篇文章最早发布在我的个人公众号上。作为在 Linuxdo 的第一帖，算是分享一下我个人做开源项目的一些折腾经历，也借此感谢 Linuxdo 论坛之前在技术上对我的帮助。
(声明：本文的部分文字内容以及部分技术栈相关的图片由 AI 辅助绘制)
LBT Climate Visualization（原名“气象数据与被动策略在线可视化系统”）这个项目，最初完全是出于“自造轮子”的冲动。
当时我在上本科的《建筑气候学》课程，发现大家常用的气候分析工具（比如 Climate Consultant）界面实在太有年代感了，而且收集气象数据也很折腾。做绿色建筑设计，明明非常需要直观的数据支持，工具却这么难用。后来受到某位老师（不知道这位老师能不能刷到我捏）用 Streamlit 制作风玫瑰图的启发，我就琢磨着：要不我自己动手搞一个现代化的气候分析工具？
V1 & V2：Streamlit 快速打样时代
为了图快，项目的初期版本直接选用了 Streamlit。作为 Python 的快速原型工具，它确实香，写几行 Python 脚本就能跑起一个 Web 应用。
在这个阶段，我陆陆续续把风玫瑰图、温度/湿度分析、太阳辐射、照度分析等基础功能都搓出来了。核心逻辑是直接调用 Ladybug Tools 的 Python SDK，解析标准的 EPW 气象文件，然后再渲染成可视化图表。
image1645×920 116 KB
V3：引入 AI 与遭遇性能瓶颈
后来大模型火了，项目在 3.0 版本顺势接入了 AI 分析功能。初衷很简单：把硬核的气象数据翻译成大白话，给非专业用户看。但通用大模型容易在专业领域“胡说八道”，所以我又给它外挂了一个 RAG（检索增强生成）系统，把绿色建筑规范和专业气候知识塞进去，让 AI 给出的建议能真正落地到工程上（在这位老师的帮助下也发了一篇论文，这位老师是我的超人！）
功能越做越丰富，但 Streamlit 的短板也越来越让人头疼。它最大的硬伤在于机制问题：用户每次交互或者改动数据，整个脚本就会从头到尾重新跑一遍。这种设计虽然完全省去了状态管理的麻烦，但性能灾难是肉眼可见的。尤其是在 AI 对话模块，只要页面一刷新，历史对话就会被强制重新渲染，体验非常割裂。再加上前端 UI 和后端逻辑全糅在一个 Python 文件里，“面条代码”越来越长，后期维护纯纯折磨。
重构：拥抱 Vue + Nuxt3 + FastAPI
转机出现在我参与 “猜宝可梦” 游戏开发（宝一把，口袋迷 AG 的粉丝应该知道）之后。当时我负责重绘 UI 和部分算法优化，在这个过程中深度接触了 Vue 框架和真正的前后端分离架构。体验过那种“展示归展示，业务归业务”的清爽感后，俺寻思：现在的项目必须重构！
经过一番评估，我把技术栈全盘迁移到了 Vue + Nuxt3 + FastAPI。
image1772×920 115 KB
新架构彻底解耦了：
- 后端 (FastAPI)：继续发挥 Python 在数据处理上的优势，保留原来的 EPW 解析、图表生成和 AI 分析逻辑，把它们全部封装成 RESTful API。
- 前端 (Nuxt3)：接管了所有的界面展示、交互和状态管理。Nuxt3 自带的服务端渲染（SSR）和基于文件的路由系统，让开发体验直线飙升。
踩坑与折腾
当然，重构的过程并不是一帆风顺的，期间踩了不少坑：
- 数据与图表序列化：以前在 Streamlit 里直接传 Python 对象就行，现在全得转成 JSON 走网络传输。特别是 Plotly 的图表配置，怎么让 Python 端生成的格式被前端 JS 完美解析，花了我不少功夫调优。
- AI 流式输出：为了让 AI 的回答能像 ChatGPT 一样流畅打字输出，流式传输被我改了又改，最后用 SSE (Server-Sent Events) 协议才搞定。
- Docker 容器编排网络：部署时我用 Docker Compose 来编排前后端，结果死活卡在容器间的网络通信上。最后妥协了一下，用服务名替代了 localhost，并配合环境变量才算跑通。（这里肯定有更优雅的解法，但限于目前的 Docker 功底，只能先贯彻“能跑就行”的原则了）。
image1729×912 120 KB
涅槃重生
重构后的新版本，体验可以说是脱胎换骨：
首先是性能自由，告别了全局刷新，点哪里响应哪里，极其丝滑；其次通过浏览器缓存和 Pinia 做状态管理，用户选过的文件和配置终于能存下来了。可视化方面，我顺手加了全年的气候数据热力图，还集成了 Ladybug 的标准色卡，焓湿图等工具看起来也更专业了。
image1795×628 185 KB
image1802×744 172 KB
写在最后
回头看这次技术大换血，其实也是我自己开发理念的一次升级——从追求“快”的单体原型，慢慢走向了结构清晰的生产级项目（也许？）。Streamlit 绝对是验证 Idea 的神器，但当你的项目对性能、交互体验和代码可维护性有更高要求时，老老实实切回成熟的 Web 框架才是正解。
目前这个项目已经持续运营了一年左右，权当是为绿色建筑领域的数字化添一块砖。在现在的 AI 浪潮下，怎么把 AI 跟传统的工程软件结合好，弄出点真正有用的东西，依然是个非常有意思且值得折腾的方向。
网友解答：--【壹】--：
image1290×920 126 KB
这篇文章最早发布在我的个人公众号上。作为在 Linuxdo 的第一帖，算是分享一下我个人做开源项目的一些折腾经历，也借此感谢 Linuxdo 论坛之前在技术上对我的帮助。
(声明：本文的部分文字内容以及部分技术栈相关的图片由 AI 辅助绘制)
LBT Climate Visualization（原名“气象数据与被动策略在线可视化系统”）这个项目，最初完全是出于“自造轮子”的冲动。
当时我在上本科的《建筑气候学》课程，发现大家常用的气候分析工具（比如 Climate Consultant）界面实在太有年代感了，而且收集气象数据也很折腾。做绿色建筑设计，明明非常需要直观的数据支持，工具却这么难用。后来受到某位老师（不知道这位老师能不能刷到我捏）用 Streamlit 制作风玫瑰图的启发，我就琢磨着：要不我自己动手搞一个现代化的气候分析工具？
V1 & V2：Streamlit 快速打样时代
为了图快，项目的初期版本直接选用了 Streamlit。作为 Python 的快速原型工具，它确实香，写几行 Python 脚本就能跑起一个 Web 应用。
在这个阶段，我陆陆续续把风玫瑰图、温度/湿度分析、太阳辐射、照度分析等基础功能都搓出来了。核心逻辑是直接调用 Ladybug Tools 的 Python SDK，解析标准的 EPW 气象文件，然后再渲染成可视化图表。
image1645×920 116 KB
V3：引入 AI 与遭遇性能瓶颈
后来大模型火了，项目在 3.0 版本顺势接入了 AI 分析功能。初衷很简单：把硬核的气象数据翻译成大白话，给非专业用户看。但通用大模型容易在专业领域“胡说八道”，所以我又给它外挂了一个 RAG（检索增强生成）系统，把绿色建筑规范和专业气候知识塞进去，让 AI 给出的建议能真正落地到工程上（在这位老师的帮助下也发了一篇论文，这位老师是我的超人！）
功能越做越丰富，但 Streamlit 的短板也越来越让人头疼。它最大的硬伤在于机制问题：用户每次交互或者改动数据，整个脚本就会从头到尾重新跑一遍。这种设计虽然完全省去了状态管理的麻烦，但性能灾难是肉眼可见的。尤其是在 AI 对话模块，只要页面一刷新，历史对话就会被强制重新渲染，体验非常割裂。再加上前端 UI 和后端逻辑全糅在一个 Python 文件里，“面条代码”越来越长，后期维护纯纯折磨。
重构：拥抱 Vue + Nuxt3 + FastAPI
转机出现在我参与 “猜宝可梦” 游戏开发（宝一把，口袋迷 AG 的粉丝应该知道）之后。当时我负责重绘 UI 和部分算法优化，在这个过程中深度接触了 Vue 框架和真正的前后端分离架构。体验过那种“展示归展示，业务归业务”的清爽感后，俺寻思：现在的项目必须重构！
经过一番评估，我把技术栈全盘迁移到了 Vue + Nuxt3 + FastAPI。
image1772×920 115 KB
新架构彻底解耦了：
- 后端 (FastAPI)：继续发挥 Python 在数据处理上的优势，保留原来的 EPW 解析、图表生成和 AI 分析逻辑，把它们全部封装成 RESTful API。
- 前端 (Nuxt3)：接管了所有的界面展示、交互和状态管理。Nuxt3 自带的服务端渲染（SSR）和基于文件的路由系统，让开发体验直线飙升。
踩坑与折腾
当然，重构的过程并不是一帆风顺的，期间踩了不少坑：
- 数据与图表序列化：以前在 Streamlit 里直接传 Python 对象就行，现在全得转成 JSON 走网络传输。特别是 Plotly 的图表配置，怎么让 Python 端生成的格式被前端 JS 完美解析，花了我不少功夫调优。
- AI 流式输出：为了让 AI 的回答能像 ChatGPT 一样流畅打字输出，流式传输被我改了又改，最后用 SSE (Server-Sent Events) 协议才搞定。
- Docker 容器编排网络：部署时我用 Docker Compose 来编排前后端，结果死活卡在容器间的网络通信上。最后妥协了一下，用服务名替代了 localhost，并配合环境变量才算跑通。（这里肯定有更优雅的解法，但限于目前的 Docker 功底，只能先贯彻“能跑就行”的原则了）。
image1729×912 120 KB
涅槃重生
重构后的新版本，体验可以说是脱胎换骨：
首先是性能自由，告别了全局刷新，点哪里响应哪里，极其丝滑；其次通过浏览器缓存和 Pinia 做状态管理，用户选过的文件和配置终于能存下来了。可视化方面，我顺手加了全年的气候数据热力图，还集成了 Ladybug 的标准色卡，焓湿图等工具看起来也更专业了。
image1795×628 185 KB
image1802×744 172 KB
写在最后
回头看这次技术大换血，其实也是我自己开发理念的一次升级——从追求“快”的单体原型，慢慢走向了结构清晰的生产级项目（也许？）。Streamlit 绝对是验证 Idea 的神器，但当你的项目对性能、交互体验和代码可维护性有更高要求时，老老实实切回成熟的 Web 框架才是正解。
目前这个项目已经持续运营了一年左右，权当是为绿色建筑领域的数字化添一块砖。在现在的 AI 浪潮下，怎么把 AI 跟传统的工程软件结合好，弄出点真正有用的东西，依然是个非常有意思且值得折腾的方向。
image1290×920 126 KB
这篇文章最早发布在我的个人公众号上。作为在 Linuxdo 的第一帖，算是分享一下我个人做开源项目的一些折腾经历，也借此感谢 Linuxdo 论坛之前在技术上对我的帮助。
(声明：本文的部分文字内容以及部分技术栈相关的图片由 AI 辅助绘制)
LBT Climate Visualization（原名“气象数据与被动策略在线可视化系统”）这个项目，最初完全是出于“自造轮子”的冲动。
当时我在上本科的《建筑气候学》课程，发现大家常用的气候分析工具（比如 Climate Consultant）界面实在太有年代感了，而且收集气象数据也很折腾。做绿色建筑设计，明明非常需要直观的数据支持，工具却这么难用。后来受到某位老师（不知道这位老师能不能刷到我捏）用 Streamlit 制作风玫瑰图的启发，我就琢磨着：要不我自己动手搞一个现代化的气候分析工具？
V1 & V2：Streamlit 快速打样时代
为了图快，项目的初期版本直接选用了 Streamlit。作为 Python 的快速原型工具，它确实香，写几行 Python 脚本就能跑起一个 Web 应用。
在这个阶段，我陆陆续续把风玫瑰图、温度/湿度分析、太阳辐射、照度分析等基础功能都搓出来了。核心逻辑是直接调用 Ladybug Tools 的 Python SDK，解析标准的 EPW 气象文件，然后再渲染成可视化图表。
image1645×920 116 KB
V3：引入 AI 与遭遇性能瓶颈
后来大模型火了，项目在 3.0 版本顺势接入了 AI 分析功能。初衷很简单：把硬核的气象数据翻译成大白话，给非专业用户看。但通用大模型容易在专业领域“胡说八道”，所以我又给它外挂了一个 RAG（检索增强生成）系统，把绿色建筑规范和专业气候知识塞进去，让 AI 给出的建议能真正落地到工程上（在这位老师的帮助下也发了一篇论文，这位老师是我的超人！）
功能越做越丰富，但 Streamlit 的短板也越来越让人头疼。它最大的硬伤在于机制问题：用户每次交互或者改动数据，整个脚本就会从头到尾重新跑一遍。这种设计虽然完全省去了状态管理的麻烦，但性能灾难是肉眼可见的。尤其是在 AI 对话模块，只要页面一刷新，历史对话就会被强制重新渲染，体验非常割裂。再加上前端 UI 和后端逻辑全糅在一个 Python 文件里，“面条代码”越来越长，后期维护纯纯折磨。
重构：拥抱 Vue + Nuxt3 + FastAPI
转机出现在我参与 “猜宝可梦” 游戏开发（宝一把，口袋迷 AG 的粉丝应该知道）之后。当时我负责重绘 UI 和部分算法优化，在这个过程中深度接触了 Vue 框架和真正的前后端分离架构。体验过那种“展示归展示，业务归业务”的清爽感后，俺寻思：现在的项目必须重构！
经过一番评估，我把技术栈全盘迁移到了 Vue + Nuxt3 + FastAPI。
image1772×920 115 KB
新架构彻底解耦了：
- 后端 (FastAPI)：继续发挥 Python 在数据处理上的优势，保留原来的 EPW 解析、图表生成和 AI 分析逻辑，把它们全部封装成 RESTful API。
- 前端 (Nuxt3)：接管了所有的界面展示、交互和状态管理。Nuxt3 自带的服务端渲染（SSR）和基于文件的路由系统，让开发体验直线飙升。
踩坑与折腾
当然，重构的过程并不是一帆风顺的，期间踩了不少坑：
- 数据与图表序列化：以前在 Streamlit 里直接传 Python 对象就行，现在全得转成 JSON 走网络传输。特别是 Plotly 的图表配置，怎么让 Python 端生成的格式被前端 JS 完美解析，花了我不少功夫调优。
- AI 流式输出：为了让 AI 的回答能像 ChatGPT 一样流畅打字输出，流式传输被我改了又改，最后用 SSE (Server-Sent Events) 协议才搞定。
- Docker 容器编排网络：部署时我用 Docker Compose 来编排前后端，结果死活卡在容器间的网络通信上。最后妥协了一下，用服务名替代了 localhost，并配合环境变量才算跑通。（这里肯定有更优雅的解法，但限于目前的 Docker 功底，只能先贯彻“能跑就行”的原则了）。
image1729×912 120 KB
涅槃重生
重构后的新版本，体验可以说是脱胎换骨：
首先是性能自由，告别了全局刷新，点哪里响应哪里，极其丝滑；其次通过浏览器缓存和 Pinia 做状态管理，用户选过的文件和配置终于能存下来了。可视化方面，我顺手加了全年的气候数据热力图，还集成了 Ladybug 的标准色卡，焓湿图等工具看起来也更专业了。
image1795×628 185 KB
image1802×744 172 KB
写在最后
回头看这次技术大换血，其实也是我自己开发理念的一次升级——从追求“快”的单体原型，慢慢走向了结构清晰的生产级项目（也许？）。Streamlit 绝对是验证 Idea 的神器，但当你的项目对性能、交互体验和代码可维护性有更高要求时，老老实实切回成熟的 Web 框架才是正解。
目前这个项目已经持续运营了一年左右，权当是为绿色建筑领域的数字化添一块砖。在现在的 AI 浪潮下，怎么把 AI 跟传统的工程软件结合好，弄出点真正有用的东西，依然是个非常有意思且值得折腾的方向。
网友解答：--【壹】--：
image1290×920 126 KB
这篇文章最早发布在我的个人公众号上。作为在 Linuxdo 的第一帖，算是分享一下我个人做开源项目的一些折腾经历，也借此感谢 Linuxdo 论坛之前在技术上对我的帮助。
(声明：本文的部分文字内容以及部分技术栈相关的图片由 AI 辅助绘制)
LBT Climate Visualization（原名“气象数据与被动策略在线可视化系统”）这个项目，最初完全是出于“自造轮子”的冲动。
当时我在上本科的《建筑气候学》课程，发现大家常用的气候分析工具（比如 Climate Consultant）界面实在太有年代感了，而且收集气象数据也很折腾。做绿色建筑设计，明明非常需要直观的数据支持，工具却这么难用。后来受到某位老师（不知道这位老师能不能刷到我捏）用 Streamlit 制作风玫瑰图的启发，我就琢磨着：要不我自己动手搞一个现代化的气候分析工具？
V1 & V2：Streamlit 快速打样时代
为了图快，项目的初期版本直接选用了 Streamlit。作为 Python 的快速原型工具，它确实香，写几行 Python 脚本就能跑起一个 Web 应用。
在这个阶段，我陆陆续续把风玫瑰图、温度/湿度分析、太阳辐射、照度分析等基础功能都搓出来了。核心逻辑是直接调用 Ladybug Tools 的 Python SDK，解析标准的 EPW 气象文件，然后再渲染成可视化图表。
image1645×920 116 KB
V3：引入 AI 与遭遇性能瓶颈
后来大模型火了，项目在 3.0 版本顺势接入了 AI 分析功能。初衷很简单：把硬核的气象数据翻译成大白话，给非专业用户看。但通用大模型容易在专业领域“胡说八道”，所以我又给它外挂了一个 RAG（检索增强生成）系统，把绿色建筑规范和专业气候知识塞进去，让 AI 给出的建议能真正落地到工程上（在这位老师的帮助下也发了一篇论文，这位老师是我的超人！）
功能越做越丰富，但 Streamlit 的短板也越来越让人头疼。它最大的硬伤在于机制问题：用户每次交互或者改动数据，整个脚本就会从头到尾重新跑一遍。这种设计虽然完全省去了状态管理的麻烦，但性能灾难是肉眼可见的。尤其是在 AI 对话模块，只要页面一刷新，历史对话就会被强制重新渲染，体验非常割裂。再加上前端 UI 和后端逻辑全糅在一个 Python 文件里，“面条代码”越来越长，后期维护纯纯折磨。
重构：拥抱 Vue + Nuxt3 + FastAPI
转机出现在我参与 “猜宝可梦” 游戏开发（宝一把，口袋迷 AG 的粉丝应该知道）之后。当时我负责重绘 UI 和部分算法优化，在这个过程中深度接触了 Vue 框架和真正的前后端分离架构。体验过那种“展示归展示，业务归业务”的清爽感后，俺寻思：现在的项目必须重构！
经过一番评估，我把技术栈全盘迁移到了 Vue + Nuxt3 + FastAPI。
image1772×920 115 KB
新架构彻底解耦了：
- 后端 (FastAPI)：继续发挥 Python 在数据处理上的优势，保留原来的 EPW 解析、图表生成和 AI 分析逻辑，把它们全部封装成 RESTful API。
- 前端 (Nuxt3)：接管了所有的界面展示、交互和状态管理。Nuxt3 自带的服务端渲染（SSR）和基于文件的路由系统，让开发体验直线飙升。
踩坑与折腾
当然，重构的过程并不是一帆风顺的，期间踩了不少坑：
- 数据与图表序列化：以前在 Streamlit 里直接传 Python 对象就行，现在全得转成 JSON 走网络传输。特别是 Plotly 的图表配置，怎么让 Python 端生成的格式被前端 JS 完美解析，花了我不少功夫调优。
- AI 流式输出：为了让 AI 的回答能像 ChatGPT 一样流畅打字输出，流式传输被我改了又改，最后用 SSE (Server-Sent Events) 协议才搞定。
- Docker 容器编排网络：部署时我用 Docker Compose 来编排前后端，结果死活卡在容器间的网络通信上。最后妥协了一下，用服务名替代了 localhost，并配合环境变量才算跑通。（这里肯定有更优雅的解法，但限于目前的 Docker 功底，只能先贯彻“能跑就行”的原则了）。
image1729×912 120 KB
涅槃重生
重构后的新版本，体验可以说是脱胎换骨：
首先是性能自由，告别了全局刷新，点哪里响应哪里，极其丝滑；其次通过浏览器缓存和 Pinia 做状态管理，用户选过的文件和配置终于能存下来了。可视化方面，我顺手加了全年的气候数据热力图，还集成了 Ladybug 的标准色卡，焓湿图等工具看起来也更专业了。
image1795×628 185 KB
image1802×744 172 KB
写在最后
回头看这次技术大换血，其实也是我自己开发理念的一次升级——从追求“快”的单体原型，慢慢走向了结构清晰的生产级项目（也许？）。Streamlit 绝对是验证 Idea 的神器，但当你的项目对性能、交互体验和代码可维护性有更高要求时，老老实实切回成熟的 Web 框架才是正解。
目前这个项目已经持续运营了一年左右，权当是为绿色建筑领域的数字化添一块砖。在现在的 AI 浪潮下，怎么把 AI 跟传统的工程软件结合好，弄出点真正有用的东西，依然是个非常有意思且值得折腾的方向。