在之前的文章\(^{[ 1 ]}\)中，原方案的设计，是基于功能实现的角度去设计的，对于功能性的拓展，考虑不全面，结合收到的反馈意见，对项目进行了拓展优化。完成的优化拓展有如下几个方面

原实现方案中预留了chatId这个字段，原chatId并未起到实际作用，是为后续功能拓展所预留的字段，在原实现方案的网页聊天中，该chatId为随机生成的UUID。

网页会话

【资料图】

固定会话的意义由几个功能来体现

支持历史消息

支持用户与会话映射（由业务系统自行实现)

类似ChatGPT官网，一个用户关联多个chatId，根据选择的会话可以查询到之前询问的历史消息和继续联系上下文进行提问。

当前实现方案提供的历史消息功能是基于本地缓存构建的，历史消息被存储在内存中，不是持久化存储，当项目重启或者垃圾回收，存储的历史消息记录就会丢失。为了方便业务系统更好的集成，持久化数据存储，提供了如下接口。

对如下接口进行拓展实现，覆盖默认的系统方案，即可完成持久化历史消息存储。

public interface ChatCacheService {    /**     * 根据会话记录查询历史记录     * @param chatId     * @return     */    List history(String chatId);    /**     * 查询历史记录     * @param chatId 会话ID     * @param limit 限制条数     * @return     */    List history(String chatId,Integer limit);    /**     * 消息写入     * @param message     */    void write(String chatId, ChatMessage message);}

lucy-chat提供了自定义注解@ChatAuth，并且将该注解添加到了所有的API上，第三方系统集成后，可以通过构建@Aspect对该注解进行拦截处理，以判断当前用户是否有权访问对应接口。

@Documented@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.METHOD,ElementType.TYPE})public @interface ChatAuth {    // it is anything    String value() default "";}

由业务系统自行实现切面，完成对接口的鉴权，该鉴权模式的优点是具有更大的自由度，可以抛出自定义异常，可以结合其他业务逻辑（如调用请求次数、频率）等进行鉴权处理。

如何构建切面鉴权，请查看 切面实现

项目采用MIT协议

https://gitee.com/Kindear/lucy-chat

请参考文章\(^{[1]}\)

更多文档请参阅 Lucy-Chat 快速上手\(^{[2]}\)

[1] Kindear.Springboot 接入 ChatGPT [EB/OL] 博客园

[2] Lucy-Chat 快速上手

关键词：