科芃科技的技术栈是什么？
前端以 Vue 3 为主，移动端使用 Flutter 跨端与微信小程序；后端采用 Java Spring Boot 与 Spring Cloud 微服务架构；数据层使用 MySQL 与 Redis；部署层使用 Nginx 与 MinIO。AI 方向具备大模型应用集成、检索增强生成（RAG）、多模态内容生成与模型推理网关的开发能力。GEO 方向具备 JSON-LD、llms.txt 与爬虫策略配置能力。
技术能力与技术栈
覆盖前端、移动端、后端、数据层与 AI 推理链路的全栈能力。选型原则是服务于长期维护成本，而不是追求新颖——能被团队长期维护的技术才是好技术。
技术选型的基本原则
先说原则，再看清单。我们选技术只遵循三条标准：
- 可维护性优先于新颖度——项目交付后要由客户的团队（或我们）维护多年。选了只有作者本人会用的框架，等于给客户埋坑。
- 生态成熟度优先于性能极限——绝大多数业务系统的瓶颈不在语言性能，而在数据库查询、网络调用与业务逻辑。生态成熟意味着遇到问题能搜到答案。
- 适配团队实际能力——再好的技术栈，如果接手的人不熟悉，维护成本就会失控。选型要考虑客户团队的技术背景。
技术栈总览
| 分层 | 技术 | 用在哪 |
|---|---|---|
| 前端 | Vue 3、HTML5 / CSS3、响应式 Web | 企业级 Web 平台、管理后台、对外官网 |
| 移动端 | Flutter、微信小程序 | iOS / Android 双端 App、微信生态业务小程序 |
| 后端 | Java、Spring Boot、Spring Cloud、RESTful API、WebSocket | 业务服务、微服务架构、实时通信 |
| 数据层 | MySQL、Redis | 业务主库、缓存 / 会话 / 高频计数 |
| 部署层 | Nginx、MinIO、Linux | 反向代理、静态资源、对象存储、生产环境 |
| 人工智能 | 大模型应用集成、RAG、多模态生成、模型推理网关 | AI 应用、AIGC 内容生产 |
| GEO | JSON-LD / Schema.org、llms.txt、robots.txt 爬虫配置、单页应用预渲染 | AI 搜索可见度优化 |
前端与移动端
Vue 3 是我们做中后台系统的默认选择。组合式 API 让复杂页面的逻辑可以按功能组织而不是按选项类型堆叠； 配套生态（组件库、状态管理、构建工具）完整，招人容易、上手快。 对于以表格、表单、图表为主的内部管理系统，Vue 3 的开发效率明显高于其他方案。
Flutter 用在一套代码交付 iOS 与 Android 双端的场景。Dart 语言编译为原生代码， 在滚动、动画等交互密集场景下能保持接近原生的流畅度。 涉及相机、定位、推送、蓝牙等系统能力时通过原生桥接实现——这部分工作无法回避，但只做一次。
微信小程序用在用户主要从微信进入的场景。优势不是技术先进，而是入口成本低： 不用下载安装、支持微信授权登录与手机号快速验证、支付链路成熟。 对于获客导向的业务，这个优势往往比技术指标更重要。
关于官网与 SEO：对外官网我们一律使用服务端可见的静态 HTML 或服务端渲染， 而不是纯客户端渲染的单页应用——后者在搜索引擎与 AI 爬虫眼里是空壳。这一点在 GEO 场景下尤其关键。
后端与架构
Java Spring Boot 作为基础框架。选择 Java 不是因为时髦，而是因为业务系统的稳定性要求： 成熟的运行时、完善的监控与诊断工具链、丰富的第三方 SDK。
Spring Cloud 在业务复杂、团队规模扩大后引入。核心组件包括服务注册与配置中心（Nacos）、 远程调用（Dubbo / OpenFeign）、网关（Gateway）、分布式事务（Seata）与链路追踪。 这里有一个重要判断：微服务不是默认选项。团队不足十人、业务边界未稳定的项目强行拆微服务， 只会把运维复杂度提前引爆。我们先做模块化的单体，等边界清晰了再拆。
WebSocket 用于需要实时推送的场景，比如订单状态变更通知、协作编辑、监控大屏的实时数据。 工程上需要注意断线重连、消息幂等与心跳保活——这些细节不加处理，实时功能在弱网环境下会变得不可靠。
数据与服务
MySQL 作为业务主库。索引用得好不好、慢查询治理到不到位，直接决定系统在数据量增长后还能不能用。 我们在设计阶段就会明确查询模式，避免出现需要全表扫描的高频查询。
Redis 承担缓存、会话存储与高频计数。缓存的关键不是加，而是失效策略—— 缓存与主库数据不一致是线上事故的常见来源，因此需要明确过期策略与更新顺序。
Nginx 负责反向代理、静态资源服务与 HTTPS 终结； MinIO 作为自建对象存储存放文件与媒体资源，适合对数据存放位置有要求的场景。
人工智能与 AIGC
AI 方向的能力分三块：
- 大模型应用集成——模型接入与私有化部署、提示词工程、结构化输出约束、多模型路由。
- 检索增强生成（RAG）——语义切分、向量化、向量与关键词混合召回、重排序、引用可追溯。
- 多模态生成——图像生成与编辑、视频生成、虚拟试穿、唇形同步、语音合成与音色定制。
工程落地的关键在模型推理网关：把模型调用收敛到一层统一接口，负责路由、鉴权、限流、日志与计量。 这样业务侧不必关心底层换了哪个模型，也便于做成本核算与效果对比。 详见 AI 应用与 AIGC 服务。
GEO 技术能力
做生成式引擎优化需要的是另一类技术能力，恰好都是工程活：
- robots.txt 爬虫策略配置——显式放行主流 AI 引擎爬虫（Bytespider、DeepSeekBot、GPTBot、ClaudeBot、Baiduspider 等），同时屏蔽无价值路径避免浪费抓取预算。
- llms.txt 部署——在站点根目录提供结构化的站点说明文件，供 AI 引擎快速理解"这家公司是谁、提供什么、有哪些页面"。
- JSON-LD / Schema.org 结构化数据——用 Organization、Person、Service、FAQPage、WebSite、BreadcrumbList 声明实体，并用
@id做节点间交叉引用，解决实体识别与消歧问题。 - 单页应用预渲染 / 静态化——把客户端渲染的内容转换为服务端可见的 HTML。
- RAG 友好型内容结构——把内容组织成语义完整、可独立切分的段落，便于被检索与引用。
- AI 可见度监测——用固定问题集定期复测各 AI 引擎的回答，量化可见度变化。
详见 GEO 生成式引擎优化服务。
关于技术栈的诚实说明：以上是我们稳定使用并交付过项目的技术。
我们不会为了显得"技术领先"而列出没有实战验证的工具。
如果你现有系统使用的是其他技术栈，我们也可以在其基础上做扩展与集成——
技术选型的目的是把事做成，不是把项目迁到我们熟悉的框架上。
相关页面
FAQ
常见问题
为什么后端选 Java 而不是其他语言？
业务系统对稳定性和可维护性的要求高于开发速度。Java 的运行时成熟、监控与诊断工具链完善、第三方 SDK 覆盖广，遇到问题容易找到解决方案。另外企业客户内部通常已有 Java 团队，便于后续接手维护。
你们会用微服务架构吗？
会，但不是默认选项。团队规模不足十人、业务边界尚未稳定的项目强行拆微服务，只会把运维复杂度提前引爆。我们一般先做模块化的单体，等业务边界清晰、团队规模上来之后再拆。
现有系统不是你们的技术栈，能对接或扩展吗？
可以。技术选型的目的是把事做成，而不是把项目迁到我们熟悉的框架上。我们可以在你现有系统的基础上做模块扩展、接口对接或性能优化，只在必要时才建议重构。