1 跨请求保存数据

服务状态的判定标准.判断一个 结构体 或 组件 是否有状态，可以依据以下几个关键标准和角度：

• 是否保存跨请求的状态或数据

有状态：如果组件/结构体在一个请求完成后，仍然保存状态或数据，供后续请求访问和使用。
无状态：如果组件/结构体仅在单次请求中处理数据，且请求完成后其状态不被保留。

有状态：

一个缓存系统保存用户登录状态或会话信息。
数据库连接池维护的连接列表，跨多个请求使用。

无状态：
一个函数式组件，其行为完全由传入的参数决定，返回结果后不保留任何状态。

2. 是否依赖外部持久存储

有状态：如果组件/结构体通过磁盘、数据库、分布式存储等维护数据，即使进程结束，数据仍可恢复。
无状态：如果组件/结构体不依赖任何持久存储，且重启或销毁后无法恢复其状态。

有状态：

数据库实体（如账户信息）通过存储库持久化到数据库。
文件系统写入的数据。

无状态：

临时计算的变量或数据，未保存到持久存储。

3. 是否在运行时维护内存中的状态

有状态：如果组件/结构体在运行时存储某些状态信息（如变量、连接、计数器），并随着系统运行发生变化。
无状态：如果组件/结构体没有任何运行时状态，或者其状态在完成任务后被清除。

有状态：

一个内存队列或缓冲区。
一个计数器对象，用于统计请求次数。

无状态：

一个只实现逻辑处理的函数（如加法函数）。

4. 是否与外部输入相关

有状态：如果组件/结构体的行为受外部输入以外的额外状态影响（如缓存、上下文）。
无状态：如果组件/结构体的行为仅受当前输入的影响，输入相同时，输出始终相同。

有状态：

一个缓存系统可能根据之前的请求返回结果。
一个用户会话管理器根据用户的登录状态返回不同响应。

无状态：

一个纯函数组件（如计算面积的函数），输入决定输出。

5. 是否需要显式初始化或销毁

有状态：需要显式初始化来配置或载入状态，并且通常需要显式销毁来释放资源或保存状态。
无状态：无需显式初始化，直接调用即可工作，完成后也无需释放资源。

有状态：

数据库连接组件需要初始化连接池。
日志系统需要初始化文件句柄。

无状态：

无需初始化和销毁的计算组件（如一个独立函数）。

6. 是否依赖上下文信息

有状态：如果组件/结构体依赖上下文（如用户会话、请求头等）决定其行为。
无状态：如果组件/结构体完全不依赖上下文。

有状态：

用户权限验证系统需要基于会话数据。
多语言支持系统依赖上下文语言信息返回内容。

无状态：

一个通用的数学运算模块与上下文无关。

7. 是否会影响后续操作

有状态：如果组件/结构体的行为或输出会影响后续操作结果。
无状态：如果组件/结构体之间没有这种交互或关联

有状态：

一个购物车模块记录用户的商品选择。
一个消息队列记录未处理的消息。

无状态：

一个用于验证密码的函数。

8 总结：

判断依据表

      判断标准			有状态							无状态
      跨请求状态			保存状态供后续使用。			请求完成后不保留状态。
      是否依赖外部存储	依赖磁盘、数据库等持久存储。	不依赖持久存储，数据临时存在内存中。
      是否维护运行时状态	运行时存储临时状态或变量（如计数器）。	不维护运行时状态，完成任务后即清除。
      是否与外部输入相关	行为受历史状态或上下文影响。	行为完全由当前输入决定。
      是否需初始化或销毁	需要显式初始化和销毁操作。	不需要显式初始化或销毁。
      是否依赖上下文信息	依赖上下文（如会话、语言）。	不依赖上下文，与业务上下文无关。
      是否影响后续操作	输出或行为影响后续组件或操作。	输出或行为独立，互不影响。

实际应用中的有状态与无状态
无状态 组件更适合现代微服务架构，因为它们更容易扩展、并行处理和复用。
有状态 组件在需要维护业务状态（如缓存、数据库）的场景中不可避免，需通过良好设计确保状态一致性。