2026-01-29:统计镜子反射路径数目。用go语言,给定一个大小为 m × n 的二值网格 grid(0 表示空格,1 表示镜子)。机器人从左上角 (0,0) 出发,目标是到达右下角 (m−1,n

2026-01-29:统计镜子反射路径数目。用go语言,给定一个大小为 m × n 的二值网格 grid(0 表示空格,1 表示镜子)。机器人从左上角 (0,0) 出发,目标是到达右下角 (m−1,n−1)。机器人每步只能向右或向下移动,但如果准备进入的格子里有镜子,它不会直接进入,而是在进入前被“反射”改换方向并跳到镜子相应一格之外的位置:

  • 若机器人想向右进入一个镜子格子,它会被转向向下并移动到该镜子的正下方格子;
  • 若机器人想向下进入一个镜子格子,它会被转向向右并移动到该镜子的正右方格子。

如果这样的反射使机器人移出网格,则该路径无效,不计入答案。注意:若反射后到达的格子仍然是镜子,会立即按照进入时的方向再发生一次反射(反射方向由当次进入的移动方向决定)。求从起点到终点的所有不同有效路径数,并对 1000000007 取模返回结果。

m == grid.length。

n == grid[i].length。

2 <= m, n <= 500。

grid[i][j] 的值为 0 或 1。

grid[0][0] == grid[m - 1][n - 1] == 0。

输入: grid = [[0,1,0],[0,0,1],[1,0,0]]。

输出: 5。

解释:

编号完整路径
1(0, 0) → (0, 1) [M] → (1, 1) → (1, 2) [M] → (2, 2)
2(0, 0) → (0, 1) [M] → (1, 1) → (2, 1) → (2, 2)
3(0, 0) → (1, 0) → (1, 1) → (1, 2) [M] → (2, 2)
4(0, 0) → (1, 0) → (1, 1) → (2, 1) → (2, 2)
5(0, 0) → (1, 0) → (2, 0) [M] → (2, 1) → (2, 2)

[M] 表示机器人试图进入一个有镜子的格子但被反射了。

题目来自力扣3665。

算法过程描述

该算法采用动态规划,逐行处理网格,并维护一个状态数组来记录到达当前行各列的路径数。其核心在于通过两个状态来区分机器人进入某个格子时的移动方向。

  1. 初始化
    • 定义模数 mod = 1_000_000_007 用于结果取模。
    • 获取网格的列数 n
    • 创建状态数组 f,其大小为 n+1(索引从0到n)。数组的每个元素是一个包含两个整数的数组 [2]int
      • f[j][0] 表示从上方格子移动到当前行第 j 列(即从 (i-1, j) 向下移动)的累计路径数。
      • f[j][1] 表示从左侧格子移动到当前行第 j 列(即从 (i, j-1) 向右移动)的累计路径数。
    • 初始化起点 (0,0) 的状态。由于机器人起点在 (0,0),并且只能向右或向下移动,因此可以理解为存在一条“从上方来”的路径和一条“从左方来”的路径到达 (0,0)(尽管逻辑上起点没有前驱)。代码通过将 f[1](对应第0列)初始化为 {1, 1} 来巧妙地设定初始状态。
  2. 遍历网格
    • 外层循环遍历网格的每一行 row
    • 内层循环遍历当前行的每一个格子 (i, j),其值为 x(0或1)。
  3. 状态转移(核心逻辑)
    对于每个格子 (i, j),根据其是否为镜子(x 的值)更新状态 f[j+1](因为 f 的索引从1开始,对应网格列索引0):
    • 情况一:当前格子是空格 (x == 0)
      • f[j+1][0] 更新(来自上方的路径):如果机器人从上方 (i-1, j) 向下移动进入这个空格,它可以继续向下一个格子移动。因此,到达此格子的路径数等于从上方到达当前格子的路径数 f[j][0] 加上从左侧到达当前格子的路径数 f[j+1][1](因为从左侧进入空格后,方向不变,可以继续向右或向下,但这里 f[j+1][1] 已经包含了从左侧到达 (i, j) 的路径信息,用于更新当前状态)。代码中的逻辑是 f[j+1][0] = (f[j][0] + f[j+1][1]) % mod
      • f[j+1][1] 更新(来自左侧的路径):如果机器人从左侧 (i, j-1) 向右移动进入这个空格,其路径数与从上方进入的情况相同,因为空格不改变方向。所以 f[j+1][1] 被设置为与 f[j+1][0] 相同的值。
      • 简单来说,对于空格,无论从哪个方向进入,都能正常通过,因此到达该格子的路径数合并了来自上方和左侧的路径。
    • 情况二:当前格子是镜子 (x == 1)镜子格子的状态转移是算法最巧妙的部分,它通过交换和叠加状态来模拟反射行为,避免了显式地追踪反射跳转。
      • f[j+1][0] 更新(来自上方的路径):如果机器人从上方 (i-1, j) 向下移动试图进入这个镜子格子,它会被反射。根据规则,向下进入镜子会被转向右,并移动到镜子正右方的格子 (i, j+1)。在动态规划的状态更新中,这个反射动作意味着:原本计划到达镜子格子 (i, j) 的路径(由 f[j][0] 表示),现在实际上被转移到了其右侧的格子 (i, j+1) 的“来自左侧的路径”上。因此,代码中 f[j+1][0] 的值被更新为 f[j+1][1],可以理解为将上方来的路径“叠加”到右侧格子来自左侧的路径上。
      • f[j+1][1] 更新(来自左侧的路径):如果机器人从左侧 (i, j-1) 向右移动试图进入这个镜子格子,它会被反射。根据规则,向右进入镜子会被转向下,并移动到镜子正下方的格子 (i+1, j)。在状态更新中,这个反射动作意味着:原本计划到达镜子格子 (i, j) 的路径(由 f[j+1][1] 表示),现在实际上被转移到了其下方格子。由于算法是逐行处理的,在计算当前行时,下方格子的状态尚未更新。因此,这里的更新 f[j+1][1] = f[j][0] 可以理解为一种状态传递或记录,确保在后续处理中能正确计算反射效果。更准确地说,它记录了由于反射,从左侧来的路径如何影响下方格子的状态。
  4. 返回结果
    • 当所有行和列都处理完毕后,状态数组 f 的最后一个元素 f[n][0] 存储的就是从起点 (0,0) 到达终点 (m-1, n-1) 的所有不同有效路径数,并对 mod 取模后的结果。这里取 f[n][0] 是因为到达终点通常可以理解为是从上方(即终点所在行的上一行)移动下来的最后一步。

复杂度分析

  • 时间复杂度:算法需要遍历网格中的每个格子一次,总共遍历 m * n 个格子。每个格子的处理都是常数时间的操作。因此,总的时间复杂度为 O(m * n)
  • 空间复杂度:算法使用了一个大小为 n+1 的状态数组 f,其中每个元素是两个整数。这个数组的大小只与列数 n 有关,与行数 m 无关。因此,总的额外空间复杂度为 O(n)

Go完整代码如下:

package main import("fmt")funcuniquePaths(grid [][]int)(ans int){const mod =1_000_000_007 n :=len(grid[0]) f :=make([][2]int, n+1) f[1]=[2]int{1,1}for_, row :=range grid {for j, x :=range row {if x ==0{ f[j+1][0]=(f[j][0]+ f[j+1][1])% mod f[j+1][1]= f[j+1][0]}else{ f[j+1][0]= f[j+1][1] f[j+1][1]= f[j][0]}}}return f[n][0]}funcmain(){ grid :=[][]int{{0,1,0},{0,0,1},{1,0,0}} result :=uniquePaths(grid) fmt.Println(result)}
在这里插入图片描述

Python完整代码如下:

# -*-coding:utf-8-*-defuniquePaths(grid): MOD =1_000_000_007 n =len(grid[0]) f =[[0,0]for _ inrange(n +1)] f[1]=[1,1]for row in grid:for j, x inenumerate(row):if x ==0: f[j +1][0]=(f[j][0]+ f[j +1][1])% MOD f[j +1][1]= f[j +1][0]else: f[j +1][0]= f[j +1][1] f[j +1][1]= f[j][0]return f[n][0]# 测试代码if __name__ =="__main__": grid =[[0,1,0],[0,0,1],[1,0,0]] result = uniquePaths(grid)print(result)
在这里插入图片描述

C++完整代码如下:

#include<iostream>#include<vector>usingnamespace std;intuniquePaths(vector<vector<int>>& grid){constint MOD =1'000'000'007;int n = grid[0].size(); vector<vector<int>>f(n +1,vector<int>(2,0)); f[1][0]=1; f[1][1]=1;for(auto& row : grid){for(int j =0; j < n; j++){int x = row[j];if(x ==0){ f[j +1][0]=(f[j][0]+ f[j +1][1])% MOD; f[j +1][1]= f[j +1][0];}else{ f[j +1][0]= f[j +1][1]; f[j +1][1]= f[j][0];}}}return f[n][0];}intmain(){ vector<vector<int>> grid ={{0,1,0},{0,0,1},{1,0,0}};int result =uniquePaths(grid); cout << result << endl;// 输出结果return0;}
在这里插入图片描述

Read more

一文吃透SBUS协议:从原理到实战(无人机/航模/机器人适用)

在无人机、航模、机器人等精密控制领域,“稳定、快速、可靠”是控制信号传输的核心诉求。传统的PWM信号虽然简单直观,但存在通道数有限、抗干扰能力弱、布线复杂等痛点。而SBUS(Serial Bus)协议——由FUTABA公司专为遥控设备设计的串行数字通信协议,凭借单线传输多通道数据、抗干扰强、延迟低的核心优势,逐渐成为行业主流。 本文将从“是什么-怎么工作-协议细节-厂家产品-接口设计-代码实现-实战技巧-常见问题”八个维度,用最通俗的语言+大量对比表格,全面拆解SBUS协议。无论你是刚入门的电子爱好者,还是需要落地项目的工程师,都能从本文中找到所需的实用信息。 一、SBUS协议基础认知:核心定位与优势对比 在深入技术细节前,我们先通过对比和基础定义,快速建立对SBUS的认知。很多人会把SBUS和常见的UART、PWM等混淆,这里先明确其核心定位:SBUS是基于反向电平UART的“应用层控制协议”,专门用于遥控器与接收机、接收机与飞控/执行器之间的控制信号传输。 1.1 为什么需要SBUS?传统方案的痛点 在SBUS出现之前,航模和早期无人机主要使用PWM或PPM协议传输控

AI驱动的自动化运维机器人:从“数字劳动力”到“智能协作者”的进化

AI驱动的自动化运维机器人:从“数字劳动力”到“智能协作者”的进化

在IT运维的战场上,一场静默的革命正在发生。传统的人力运维模式,面对日益复杂的混合云架构、海量微服务与瞬息万变的业务需求,已显露出疲态。重复、繁琐、高风险的日常操作消耗着工程师的精力,而突发的故障与变更则让他们疲于奔命。企业亟需一种全新的力量,来打破人力瓶颈,释放创新潜能。 AI驱动的自动化运维机器人,正是这股破局之力。它并非冰冷的脚本集合,而是融合了UI自动化、人工智能(AI)与智能编排的“数字员工”。它能够模拟人类操作,理解复杂意图,并自主执行从日常巡检到故障自愈的全链路任务,标志着运维从“人力密集型”向“人机协同智能化”的根本性转变。 一、传统运维的“人力困局”:在重复与风险中内耗 运维工程师的日常,常常陷入一种价值感低迷的循环: 1. “永动机”式的重复劳动:每日登录数十个系统查看状态、手动执行数百台服务器的补丁更新、反复填写格式化的巡检报告、在多个平台间“搬运”数据以创建工单……这些高度重复、规则明确的工作,占据了工程师70%以上的时间,却难以带来成长与成就感。 2.

PinMe——极简、免费和无需服务器的开源前端部署工具

PinMe——极简、免费和无需服务器的开源前端部署工具

PinMe是一个开源的前端部署工具,它通过将静态网站文件上传到去中心化的IPFS网络来实现快速发布,主打极简、免费和无需服务器,目前Github 1.7k stars。 Github地址:https://github.com/glitternetwork/pinme PinMe 的官方网站:https://pinme.eth.limo/ 如何使用PinMe? 包含两种部署方式,都可实现快速极简部署 方式一:Deploy from Terminal(使用命令行的方式) 全局安装: npm install -g pinme 上传已经打包后的项目文件: pinme upload <folder/file-path> 成功上传文件并完成部署后点击链接即跳转PinMe官网,显示项目详情(包含项目网页预览)与简化后的项目链接: 点击"Your Site Link"

不用部署服务器,也能给前端 / 客户演示?内网穿透实战分享

不用部署服务器,也能给前端 / 客户演示?内网穿透实战分享

在日常开发中,经常会遇到一个很现实的问题:  功能已经在本地开发完成了,但前端同事、测试、客户都看不到效果。 很多人的第一反应是: 部署一套测试服务器。 但实际情况往往是 * 服务器没准备好 * 只是临时演示 * 改动频繁,反复部署很浪费时间 后来我发现,其实根本不需要部署服务器,用内网穿透就能很优雅地解决这个问题。 一、真实场景说明 场景 1:给前端联调接口 后端服务跑在本地: http://localhost:8080 问题是: * 前端在外地 * 无法访问本地接口 * 每次改接口都要重新部署 场景 2:给客户演示功能 * 新功能刚开发完 * 客户想先看看效果 * 但还没上线正式环境 这时候再去搞服务器,明显有点“杀鸡用牛刀”。 二、传统方案为什么不太合适? 对于“临时演示 / 联调”来说,都太重了。 三、解决方案:内网穿透 内网穿透的核心思路只有一句话: 把你本地的服务,