深思慎考-CSDN博客

深思慎考

码龄10年

108,723

总访问量
108

原创
998

粉丝
59

关注

IP 属地：四川省

加入CSDN时间： 2016-03-26

个人简介：我很懒，不想简介

查看详细资料

个人成就

获得2,107次点赞
内容获得73次评论
获得2,105次收藏
博客总排名13,251名
原力等级

原力等级

5

原力分

1,083

本月获得

12

TA关注的专栏 0

TA关注的收藏夹 0

TA关注的社区 2

TA参与的活动 12

兴趣领域设置

编程语言

python

创作活动更多

AI 镜像开发实战征文活动

随着人工智能技术的飞速发展，AI 镜像开发逐渐成为技术领域的热点之一。Stable Diffusion 3.5 FP8 作为强大的文生图模型，为开发者提供了更高效的图像生成解决方案。为了推动 AI 镜像开发技术的交流与创新，我们特此发起本次征文活动，诚邀广大开发者分享在 Stable Diffusion 3.5 FP8 文生图方向的实战经验和创新应用本次征文活动鼓励开发者围绕 Stable Diffusion 3.5 FP8 文生图方向，分享以下方面的内容： 1. 技术实践与优化 - Stable Diffusion 3.5 FP8 模型架构解析与优化技巧 - 文生图生成效果的提升方法与技巧 - 模型部署与加速策略，例如使用 Hugging Face、Diffusers 等工具 - 针对特定场景（例如二次元、写实风）的模型微调与定制化开发 2. 应用场景探索 - Stable Diffusion 3.5 FP8 在不同领域的应用案例分享，例如游戏设计、广告创意、艺术创作等 - 利用 Stable Diffusion 3.5 FP8 实现图像编辑、图像修复、图像增强等功能的探索 - 结合其他 AI 技术（例如 NLP、语音识别）构建更强大的应用 3. 创新应用与思考 - 基于 Stable Diffusion 3.5 FP8 的创新应用场景设计 - AI 镜像开发的未来发展方向的思考与展望 - 对 AI 镜像开发伦理、安全等问题的探讨

28人参与去参加

更多

微服务即时通讯系统（服务端）——网关服务设计与实现（7）

单一入口：所有请求都走网关，好管理、好监控职责分离：HTTP管请求，WebSocket管推送，各干各的无状态：网关自己不存用户数据，全放Redis只转发不处理：业务逻辑交给专门的服务实时感知：谁在线、谁断线，心里有数。

博文更新于 2025.12.04 ·

微服务即时通讯系统——好友子服务设计与实现（7）

/好友列表获取// 请求标识ID// 当前请求的发起者用户ID//登录会话ID--用于网关进行身份识别--其他子服务用不到//要返回的用户信息//好友删除//当前用户ID//要删除的好友ID//添加好友--发送好友申请//申请人id//被申请人id//通知事件id//好友申请的处理//通知事件id//是否同意好友申请//申请人的用户id// 被申请人。

博文更新于 2025.11.26 ·

深入理解最长递增子序列的计数问题：从思路到推导实现

我们需要定义两个长度为n的数组（n为numsdp[i]：以nums[i]为结尾的最长递增子序列的长度；count[i]：以nums[i]为结尾的最长递增子序列的个数。

博文更新于 2025.11.22 ·

微服务即时通讯系统——消息管理子服务设计与实现（6）

我们有两个核心的 Protobuf 文件，分别定义了消息管理的 RPC 服务接口以及相关的数据结构。1.：定义 RPC 服务接口这个文件主要包含了三个 RPC 方法，分别用于获取历史消息、获取最近消息和搜索消息。// 引入基础数据结构定义// 获取历史消息请求// 请求ID，用于追踪请求// 聊天会话ID// 开始时间戳// 结束时间戳// 用户ID（可选，用于权限验证等）// 会话ID（可选，可能用于标识客户端会话）// 获取历史消息响应// 对应请求的ID// 请求是否成功。

博文更新于 2025.11.21 ·

微服务即时通讯系统（服务端）——消息转发微服务设计与实现详解(5)

基于C++的分布式即时通讯系统中的消息转发微服务，负责处理用户消息的转发逻辑。该服务使用brpc框架构建RPC服务，通过etcd实现服务注册与发现，MySQL存储聊天会话成员信息，RabbitMQ进行消息发布。gittee完整项目代码。

博文更新于 2025.11.15 ·

微服务即时通讯系统（服务端）——用户子服务实现逻辑全解析（4）

职责单一：专注用户身份与信息管理，不耦合其他业务逻辑；分层存储：MySQL 存储核心数据、Redis 存储高频临时数据、ES 支撑搜索，各取所长；高扩展性：通过 etcd 实现服务发现，支持多节点部署与动态扩容；安全性强：完善的参数校验、登录态管理、验证码机制，保障系统安全；跨服务兼容：基于 brpc 构建标准化 RPC 接口，便于与其他微服务集成。该实现方案可直接支撑即时通讯系统的核心用户管理需求，同时预留了扩展空间（如第三方登录、用户标签管理等），具备较强的实用性与可扩展性。

博文更新于 2025.11.14 ·

从正向困境到反向破局：详解地下城游戏的动态规划解法

重新设计dp[i][j]从房间 (i,j) 走到终点 (m-1,n-1)，骑士需要的最低健康点数（进入 (i,j) 时的健康值至少为多少，才能存活到终点）。状态仅依赖于后续路径（下方和右方的房间），而后续路径的状态是确定的（因为我们从终点倒推）。「地下城游戏」的解法关键在于扭转思考方向：当正向路径的状态依赖未来信息时，反向推导能将 “未来信息” 转化为 “已知条件”，从而让状态转移变得明确。正向 DP 的困境：状态依赖未来路径，无法独立确定。

博文更新于 2025.11.14 ·

算法:动态规划——解码方法问题

条件（当前字符s[i]细分条件递推公式示例非 ‘0’前一个是 ‘0’"105"→非 ‘0’前一个非 0，s[i-1..i]合法，i>=2"123"→非 ‘0’前一个非 0，s[i-1..i]不合法"135"→非 ‘0’i=1s[0..1]合法dp[i] = 2"12"→dp[1] = 2‘0’s[i-1..i]合法i>=2）或 1（i=1"120"→；"10"→dp[1] = 1‘0’s[i-1..i]不合法返回 0"30"→直接返回 0本题解的核心思路是“先特殊后一般”

博文更新于 2025.11.10 ·

从海洋逆向探索：417. 太平洋大西洋水流问题深度解析

解决「太平洋大西洋水流问题」的关键在于逆向思维，利用水流的可逆性将「判断单元格流向海洋」转化为「判断海洋能否反向到达单元格」，从而将时间复杂度从 O ((mn)²) 优化为 O (mn)。反向标记：从两大洋边界出发，用 DFS/BFS 标记各自的可达区域。求交集：两个可达区域的重叠部分即为答案。这种「逆向遍历 + 边界出发」的思路，在处理「可达性问题」（尤其是边界明确的场景）时具有广泛应用，例如「岛屿问题」「水流问题」等，可大幅提升算法效率。

博文更新于 2025.11.08 ·

图解 LCR 084. 全排列 II：决策树剪枝实战，攻克重复排列难题

解决含重复元素的全排列问题，关键在于「识别并剪枝决策树中的重复分支排序预处理：让重复元素相邻，为剪枝提供判断依据；同一层剪枝：通过used[i-1]过滤同一层的重复选择；路径去重：通过used数组过滤同一路径的重复选择。回溯算法的本质是「穷举 + 剪枝」，而本题的核心价值在于教会我们：如何通过预处理（排序）和精准的剪枝条件，将「可能产生重复结果」的穷举，优化为「无重复结果」的高效搜索。

博文更新于 2025.11.06 ·

微服务即时通讯系统（服务端）——文件存储模块全链路设计与实现（3）

首先通过 Protobuf 定义服务接口与数据结构，明确客户端与服务端的通信契约，这是微服务解耦的基础。set(target "fileServer") # 服务端程序目标名set(test_client "testClient") # 测试程序目标名# 生成服务端程序：依赖业务源码和proto生成的代码# 生成测试程序：依赖测试源码和proto生成的代码核心：将手动编写的src_files和自动生成的proto_srcs关联到目标，确保编译时能找到所有代码。

博文更新于 2025.11.03 ·

算法：从特殊到一般——拆解两两交换链表节点的递归解法

cur：当前链表的第一个节点（需要被交换到第二个位置）；next：当前链表的第二个节点（需要被交换到第一个位置，成为新头节点）；tail：剩余节点的头（即next->next，需要递归处理的部分，需要考虑为空的特殊情况）。// 第一个节点// 第二个节点// 剩余节点的头两两交换链表节点的递归解法，本质是将大问题拆成 “前 2 个节点” 和 “剩余节点” 两个子问题前 2 个节点：直接交换指针，完成局部处理；剩余节点：通过递归复用相同的处理逻辑，得到已交换的子链表；

博文更新于 2025.11.03 ·

算法: 从特殊到一般——彻底弄懂汉诺塔问题的递归解法

很多人学递归时会陷入 “逐行跟踪每一步” 的误区，导致越看越乱。其实通过汉诺塔问题我们能发现：递归的本质是 “信任”—— 当我们写_hanota(A, C, B, n-1)时，不需要关心这 n-1 个圆盘具体怎么移，只需要相信 “这个函数能正确地把 n-1 个圆盘从 A 移到 B（借助 C）”。而这种 “信任” 的基础，正是我们从特殊情况（n=1、n=2、n=3）中验证过的规律：终止条件（n=1）是确定可行的；分治逻辑（n→n-1）是正确的，能把大问题拆成小问题，直到触发终止条件。

博文更新于 2025.11.02 ·

微服务即时通讯系统（服务端）——Speech 语音模块开发(2)

首先通过//请求ID//语音数据//用户ID//登录会话ID -- 网关进行身份鉴权//请求ID//请求处理结果标志//失败原因//识别后的文字数据//语音识别Rpc服务及接口的定义通过 protoc 编译生成与，作为 RPC 接口的基础代码。低耦合：工具类（ASRTool、EtcdTool）与业务逻辑分离，便于替换第三方 API 或服务发现组件。高可用：etcd 租约与实时监听确保服务上下线感知，轮询策略实现负载均衡。易扩展。

博文更新于 2025.10.26 ·

微服务即时通讯系统——整体架构和组件(1)

高扩展性：各服务可独立扩容（如消息服务压力大时单独增加实例）高可用性：单个服务故障不影响整体系统（如文件服务故障时，文本消息仍可发送）开发效率提升：团队可按服务分工，并行开发，接口定义清晰后互不干扰技术适配灵活：不同服务选择最适合的技术栈（如消息服务用 Elasticsearch，用户服务用 MySQL）

博文更新于 2025.10.22 ·

调用百度云语音识别服务——实现c++接口识别语音

client是语音识别的C++客户端，为使用语音识别的开发人员提供了一系列的交互方法。百度云语音识别 API 提供了稳定、高效的语音转文字能力，本文将以。是在创建完毕应用后，系统分配给用户的，均为字符串，用于标识用户，为访问做签名验证，可在AI服务控制台中的。建议使用简单的SDK调用，再百度云官方下载即可。为例，手把手教你用 C++ 实现调用，从前期准备到代码落地，每一步都清晰可操作。在写代码前，我们需要完成百度云账号配置和开发环境准备，这是调用 API 的基础。在百度云控制台中创建，常量。

博文更新于 2025.10.22 ·

字符串相乘：从暴力算法到规律优化

效率极高：避免了所有字符串插入操作和中间结果的字符串存储逻辑清晰：直接模拟了乘法的数学本质内存友好：使用数组存储中间结果，内存开销稳定。

博文更新于 2025.10.21 ·

最长回文子串：从暴力破解到动态规划再到中心扩展

回文子串：连续的字符序列，正读与反读相同（如 “bb”“aba”，区别于 “abcba” 这种回文串，子串要求连续）。最长：需在所有回文子串中找到长度最大的，若有多个长度相同的，返回任意一个即可。如何高效遍历所有可能的子串，避免遗漏；如何快速判断一个子串是否为回文，减少冗余计算；如何优化时间复杂度，避免暴力算法的低效问题。解决 “最长回文子串” 的优化路径，本质是减少冗余计算暴力算法的冗余在于 “重复判断回文”，动态规划通过预存状态消除了这一冗余；

博文更新于 2025.10.19 ·

算法——字母异位词分组：从基础判断到高效分组的解题推导

若两个字符串中，每个字符出现的次数完全相同（不考虑顺序），则称它们为字母异位词。例如 “eat” 和 “tea”：两者都包含 1 个 ‘a’、1 个 ‘e’、1 个 ‘t’，属于异位词；而 “eat” 和 “tan” 因字符种类不同（前者有 ‘e’，后者有 ‘n’），不属于异位词。解决 “分组异位词” 问题的关键，本质是找到一种“哈希键”—— 让所有异位词对应同一个键，非异位词对应不同的键，再用哈希表（如）按键分组。解决 “字母异位词分组” 问题的核心是“找到异位词的统一标识”

博文更新于 2025.10.19 ·

RabbitMQ 入门：基于 AMQP-CPP 的 C++ 实践指南与二次封装

RabbitMQ 作为主流的消息中间件，凭借高可靠性、灵活的路由策略和跨语言支持，广泛应用于分布式系统解耦、异步通信场景。本文将以 C++ 的 AMQP-CPP 库为核心，从通信模式到核心接口，带你快速上手 RabbitMQ 的开发。AMQP-CPP 是 RabbitMQ 的 C++ 客户端库，提供两种网络通信模式，可根据项目的事件循环依赖灵活选择。TCP 模式需手动实现网络层逻辑，核心是继承类并完成关键函数重写，适合需要深度定制事件循环（如用 select/epoll）的场景。2. 扩展模式：借助第三方

博文更新于 2025.10.19 ·