该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/competition/2026-cimc-siemens-cup-industrial-embedded-systems-development

初赛总成绩 = 实施过程总分（100分）× 60% + 技术文档与答辩视频（40%）

看完了？说点什么呢

sscanf 是 C 语言中一个非常方便的函数，它可以从字符串中轻松地提取格式化的数据。然而，它的方便也伴随着一些非常隐蔽的陷阱。如果你不了解它的工作机制，很容易写出看似正常但实际存在严重漏洞的代码，尤其是在嵌入式和单片机开发中，这类问题常常导致程序卡死或行为异常。

本文档旨在总结 sscanf 最核心的陷阱，并提供更安全、更健壮的替代方案。

陷阱一：最经典的“部分匹配”陷阱

核心误解：认为 sscanf 返回值大于0就代表整个格式串都匹配成功了。

事实：sscanf 在遇到第一个不匹配的字符时就会立即停止，并返回它在停止前已经成功赋值的变量数量。

场景重现

假设你的代码如下，你的输入是 "LED1:OFF"：

uint8_t led_temp = 0;
if (sscanf(cmd, "LED%hhu:ON", &led_temp) == 1) {
    // 你以为只有 "LED1:ON" 才能进入这里
    // 但 "LED1:OFF" 也进来了！
    printf("LED %u Turned Up\n", led_temp); 
}

分解过程：

sscanf 在匹配 "LED%hhu:ON" 时，它的内心活动是这样的：

1. L, E, D -> 匹配成功。
2. %hhu -> 匹配到数字 1，并成功赋值给 led_temp。（成功赋值数量：1）
3. : -> 匹配成功。
4. O -> 匹配成功。
5. N -> 期望是'N'，但输入是'F'。不匹配！立即停止！

最终结果：sscanf 在停止前成功赋值了 1 个变量 (led_temp)，所以它的返回值是 1。if (1 == 1) 条件成立，程序错误地进入了处理 "ON" 的逻辑。

陷阱二：数值溢出陷阱

sscanf 在处理超出变量范围的数值时，并不会告诉你出错了。 核心误解：认为 sscanf 会自动处理数值范围问题。 事实：sscanf 不会进行范围检查。如果提供的数字超出了变量类型的存储范围，它会发生“回绕”（wraparound），得到一个完全错误的值，但函数返回值依然是 1，让你误以为转换成功。

场景重现

假设 led_temp 是 uint8_t (范围 0-255)，输入是 "LED999:ON"。

uint8_t led_temp = 0; // 只能存 0-255
if (sscanf("LED999:ON", "LED%hhu:ON", &led_temp) == 1) {
    // 程序会进入这里
    // 但 led_temp 的值是 231 (999 % 256)
    // 而不是 999！
    printf("Value: %u\n", led_temp); 
}

这是一个非常危险的逻辑 Bug，因为程序在处理一个错误的数据，但它自己却毫不知情。

如何安全地解析字符串？

既然 sscanf 有这么多问题，我们应该如何编写健壮的解析代码呢？

方案一：先验证，再解析

将“验证字符串格式”和“提取数字”这两个步骤分开。

#include <string.h>

void process_command(const char* cmd) {
    uint8_t led_temp = 0;
    
    // 1. 先用更严格的字符串函数判断命令类型
    if (strstr(cmd, ":ON") != NULL) {
        // 2. 确认是ON命令后，再用sscanf提取数字，此时更安全
        if (sscanf(cmd, "LED%hhu:ON", &led_temp) == 1) {
            printf("ON command for LED %u\n", led_temp);
        }
    } else if (strstr(cmd, ":OFF") != NULL) {
        if (sscanf(cmd, "LED%hhu:OFF", &led_temp) == 1) {
            printf("OFF command for LED %u\n", led_temp);
        }
    }
}

优点：代码逻辑清晰，易于阅读和维护。

方案二：使用 strtol 系列函数

对于任何严肃的项目，尤其是处理外部输入时，strtol (string to long) 和 strtoul (string to unsigned long) 是最佳选择。它们提供了精细的错误检查机制。

#include <stdlib.h>
#include <errno.h>
#include <limits.h>

void process_command_robust(const char* cmd) {
    // 假设命令是 "LED123:ON"
    if (strncmp(cmd, "LED", 3) != 0) return;

    const char* num_start = cmd + 3;
    char* end_ptr; // 将指向数字之后第一个字符的地址

    errno = 0; // 清空错误码
    unsigned long value = strtoul(num_start, &end_ptr, 10);

    // 检查1：数字后面是否有垃圾字符？
    // 正确的格式下，end_ptr应该指向 ":"
    if (end_ptr == num_start || *end_ptr != ':') {
        printf("Error: Invalid format.\n");
        return;
    }
    
    // 检查2：是否溢出？
    if (errno == ERANGE || value > UCHAR_MAX) { // UCHAR_MAX == 255
        printf("Error: Number out of range.\n");
        return;
    }
    
    // 所有检查通过，现在才是安全的值
    uint8_t led_temp = (uint8_t)value;

    // 最后检查命令是ON还是OFF
    if (strcmp(end_ptr, ":ON") == 0) {
        printf("Robust ON for LED %u\n", led_temp);
    } else if (strcmp(end_ptr, ":OFF") == 0) {
        printf("Robust OFF for LED %u\n", led_temp);
    }
}

优点：极致安全。能检查溢出、能检查非法格式、能检查多余字符。

总结与建议

最后的忠告：永远不要高估 sscanf 的能力，也永远不要低估用户输入“惊喜”数据的能力。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/DevNotes/debug-dma-plus-space-interrupt-problem

程序逻辑错误：DMA+空闲中断的“伪中断”问题

问题：USART1 和 USART3 的 DMA 接收功能在刚上电时无效，必须手动按一下复位键后才能正常工作。

分析：这是“DMA+空闲中断”方案中一个典型的“竞态条件”问题。原因如下：

• STM32 一上电，其 RX 引脚就已经接收到了来自电脑串口工具的“空闲”高电平。
• 当初始化代码执行到使能“空闲中断”的那一刻，USART 外设立即检测到这个已经存在的空闲状态，产生了一次“伪”的空闲中断。
• 这次中断被错误地处理了（因为 DMA 还没收到任何数据），导致系统错过了对第一帧真实数据的响应。
• 手动复位时，时序略有不同，规避了这个问题。

解决方案：在启动 DMA 接收、使能空闲中断之前，强制清除一次 USART 的空闲标志位。代码实现为：

__HAL_UART_CLEAR_IDLEFLAG(&huartX); // 清除标志
HAL_UARTEx_ReceiveToIdle_DMA(&huartX, ...); // 启动DMA接收

代码结构优化——初始化与业务逻辑分离

问题分析：即使加入了清除标志位的代码，放在 Init 函数里效果依然不理想。其深层原因是：

• 在 main 函数中，MX_USART1_UART_Init 执行完后，程序继续执行了其他外设的初始化 (MX_I2C2_Init, MX_USART3_UART_Init 等)。
• 在一个不稳定的、动态的初始化序列中途提前启动一个需要持续运行的后台任务（如 UART DMA），很容易被后续其他外设的初始化动作（如重设 DMA 通道、改变时钟、修改中断优先级等）所干扰，导致失败。

解决方案：

1. 移除MX_..._Init() 函数中所有业务启动相关的代码 (如 HAL_UARTEx_ReceiveToIdle_DMA)，让它只负责纯粹的硬件参数配置。
2. 将业务启动代码，连同修复方案，统一迁移到 main 函数的 /* USER CODE BEGIN 2 */ 区域。

结果：确保了所有硬件外设都配置完毕，系统进入稳定状态后，才启动 UART DMA 接收等应用层任务。程序行为变得可靠且符合预期。

更新:要在两个串口外设初始化之前加一句 HAL_Delay(500); 延迟函数，否则USART3的DMA接收也可能失效.

总结

1. 警惕时序和竞态条件：中断、DMA 等异步操作极易出现时序问题。“上电异常，复位正常”是典型信号。
2. 分离硬件配置与业务启动：这是最重要的原则。
   • 配置：让 MX_..._Init 函数只做一件事——根据 CubeMX 的设置配置好硬件寄存器，让硬件处于“待命”状态。
   • 启动：在 main 函数中，等待所有硬件配置完成后，再按业务逻辑顺序启动它们（比如开启 DMA、启动定时器 PWM 等）。

遵循第2点原则，可以避免 90% 以上难以排查的嵌入式系统初始化问题，也是代码走向专业和稳健的必经之路。

看完了？说点什么呢

最近学习视觉测控，需要用到Python，用AI生成一些常用命令，方便查询

Miniconda 是一个轻量级的 Conda 安装程序。它包含了 Conda、Python、它们所依赖的包，以及少量其他有用的包。这个速查手册旨在帮助你快速找到并使用最核心、最常用的 Miniconda 命令。

环境管理 (Environments)

管理独立隔离的开发环境是 Conda 最强大的功能之一。

创建新环境

• 创建一个包含特定 Python 版本的环境：

  conda create --name myenv python=3.9
  

  myenv 是你的环境名称，python=3.9 是你希望安装的 Python 版本。

• 创建一个包含特定软件包的空环境：

  conda create --name myenv numpy pandas
  

• 完整克隆一个已存在的环境：

  conda create --name newenv --clone oldenv
  

激活与退出环境

• 激活环境 (Windows):

  conda activate myenv
  

• 激活环境 (macOS / Linux):

  source activate myenv
  

  或者更通用的：

  conda activate myenv
  

• 退出当前环境，返回 base 环境：

  conda deactivate
  

查看环境

• 列出所有已创建的环境：

  conda env list
  

  或者

  conda info --envs
  

  当前激活的环境会有一个 * 标记。

删除环境

• 删除指定名称的环境及其所有包：

  conda env remove --name myenv
  

包管理 (Packages)

在激活的环境中，你可以轻松管理软件包。

安装包

• 在当前环境中安装包：

  conda install numpy
  

• 安装多个包：

  conda install numpy pandas matplotlib
  

• 安装指定版本的包：

  conda install numpy=1.20.3
  

• 从特定的渠道 (channel) 安装包 (例如 anaconda, conda-forge)：

  conda install -c conda-forge beautifulsoup4
  

查看已安装的包

• 列出当前环境中所有已安装的包：

  conda list
  

• 搜索可用的包版本：

  conda search beautifulsoup4
  

更新包

• 更新当前环境中的单个包：

  conda update numpy
  

• 更新当前环境中所有可更新的包：

  conda update --all
  

删除包

• 从当前环境中删除一个包：

  conda remove numpy
  

Conda 自身管理

• 更新 Conda 到最新版本：

  conda update -n base -c defaults conda
  

  或者一个更简洁的命令：

  conda update conda
  

• 查看 Conda 版本：

  conda --version
  

  或者

  conda info
  

渠道管理 (Channels)

Channels 是 Conda 用来查找和安装包的远程仓库。

• 查看当前配置的渠道列表：

  conda config --show channels
  

• 添加新的渠道 (例如，添加 conda-forge 并设为最高优先级):

  conda config --add channels conda-forge
  

• 移除指定的渠道:

  conda config --remove channels conda-forge
  

小贴士: 将最常用的渠道（如 conda-forge）置于 defaults 之上，可以帮助你安装到更多更新、更全面的社区维护的包。使用 --add 会将新渠道添加到列表顶部，使其具有最高优先级。

前言

暑假在家闲来无事，翻出一个闲置许久的 HC-05 蓝牙模块，正好拿来玩玩。稍微查了一下，它说白了就是一个无线串口桥接工具，用手机上的蓝牙调试软件连接后，实际通信效果和有线串口没啥区别，没什么需要额外学的。

想起之前学习上挖过的坑，计划学习数据解包/封包还没有填上，正好借机会学习一下。

蓝牙模块

我使用的是立创天空星STM32F407VGT6，将 HC-05 的 TXD , RXD 连接到单片机的 USART3 对应引脚，其逻辑电平3.3V，使用5V电压驱动。串口方案使用了DMA + 空闲中断 + 环形缓存区。

当EN/KEY引脚处于低电平或悬空状态时，HC-05处于默认模式（数据模式），手机使用蓝牙调试软件连接 HC-05 发送数据， HC-05 自动会转发数据到单片机。

当EN/KEY引脚被拉至高电平时，HC-05模块将进入AT指令模式。此模式允许用户通过串口向模块发送特定的“AT指令”，以配置模块的各种参数。

自定义数据包

一个设计良好的数据包通常包含以下部分

为了练习，设计了一个简单情景，通过手机与蓝牙模块通信，控制开发版上6个LED。

自定义的数据包格式如下:

A. 设置LED状态 (CMD: 0x01)

• 方向: 手机/上位机 -> 开发板
• 功能: 控制开发板上6个LED的亮灭状态。
• 数据字段 (Data):
  • 长度 (Length): 1字节。
  • 内容: 一个8位字节，其中低6位（Bit 0 ~ Bit 5）分别对应6个LED的状态。1代表点亮，0代表熄灭。
• 示例: 点亮LED1和LED3 (0b00000101 = 0x05)。
  • 完整数据包**: AA 55 01 01 05 07
  • 校验和: 0x01 + 0x01 + 0x05 = 0x07

B. 查询LED状态 (CMD: 0x02)

• 方向 手机/上位机 -> 开发板
• 功能: 请求开发板返回当前所有LED的状态。
• 数据字段 (Data):
  • 长度 (Length): 0字节。数据字段为空。
• 示例: 发送查询命令。
  • 完整数据包: AA 55 02 00 02
  • 校验和: 0x02 + 0x00 = 0x02

C. 响应LED状态 (CMD: 0x82)

• 方向: 开发板 -> 手机/上位机
• 功能: 作为对0x02查询命令的回复，上报当前LED的状态。
  • 设计说明: 响应命令码通常在请求命令码的基础上将最高位置为1（即 请求码 + 0x80），这是一种常见的协议设计模式。
• 数据字段 (Data):
  • 长度 (Length): 1字节。
  • 内容: 与0x01命令的数据格式完全相同，表示当前LED的实际状态。
• 示例: 回复当前LED1和LED3亮着的状态。
  • 完整数据包: AA 55 82 01 05 88
  • 校验和: 0x82 + 0x01 + 0x05 = 0x88

数据包处理

为什么要用状态机？

根据上面的设计，确定我们的数据包格式如下

| 包头1 (0xAA) | 包头2 (0x55) | 命令 (1字节) | 长度 (1字节) | 数据 (N字节) | 校验和 (1字节) |

按照直觉，我可能会写出这样的“面条代码”

// 伪代码
void process_data(uint8_t* data, int len) {
    int i = 0;
    if (data[i] == 0xAA) {
        i++;
        if (data[i] == 0x55) {
            i++;
            uint8_t cmd = data[i];
            i++;
            uint8_t data_len = data[i];
            i++;
            // ...一堆嵌套的 if-else...
        }
    }
}

这种代码的执行流程是线性的、过程化的，根据一系列条件判断来决定下一步操作，其坏处显而易见：层层嵌套，逻辑混乱，非常容易出错，而且极难扩展。

显然，这种“一条路走到黑”的面向过程写法，在处理带有上下文逻辑的流式数据时，已经力不从心。

那么，我们来分析一下这种混乱的根源是什么？

根本原因在于，我们的解析逻辑不仅取决于当前读到的字节，更依赖于一个隐藏的“上下文”，也就是“目前读到了数据包的哪个部分”。

在上面的代码里，试图用一个i++和代码的嵌套层次来被人为地“记住”这个上下文，但效果显然不理想。

既然解析过程存在不同的“上下文”，为何不换一种思维模式呢？我们可以把这些上下文明确地定义出来，变成一个个清晰的“状态”。

比如：

• 等待包头1的状态
• 等待包头2的状态
• 等待命令字的状态
• ...等等

如果程序能在这些明确的“状态”之间进行切换，代码结构就会清晰许多了。

这正是接下来要介绍的核心思想——有限状态机（Finite State Machine, FSM）。

状态机是一种强大的设计模式，简单来说，状态机思想的核心，就是把一个复杂的逻辑过程，拆分成有限个、互不重叠的“状态”，并明确定义在什么条件下（事件），从一个状态切换到另一个状态。通过它，我们可以将上面那团乱麻似的if-else，重构为结构清晰、易于维护的代码。它天然地适合用来处理像数据包解析这样，行为依赖于历史步骤的场景。

状态机实现

1. 定义状态/命令

用一个枚举类型 enum 定义所有可能的状态。初始状态为 STATE_HEADER1 等待包头1 (0xAA)。

typedef enum {
    STATE_HEADER1,      // 等待包头1 (0xAA)
    STATE_HEADER2,      // 等待包头2 (0x55)
    STATE_CMD,          // 等待命令字
    STATE_LEN,          // 等待数据长度
    STATE_DATA,         // 接收数据
    STATE_CHECKSUM      // 等待校验和
} ParserState;

static ParserState current_state = STATE_HEADER1; // 初始状态

定义协议命令常量。

#define PACKET_HEADER_1         0xAA
#define PACKET_HEADER_2         0x55
#define CMD_SET_LED             0x01
#define CMD_QUERY_LED           0x02
#define CMD_RESPONSE_LED        0x82

2. 状态机核心

状态机核心在于 parse_byte(uint8_t byte) 函数。它的工作模式是逐字节驱动的

串口功能已将数据存入环形缓存区，并开始逐字节处理数据。

/**
 * @brief 蓝牙数据处理任务，调用状态机解析器
 */
void BT_Task()
{
    uint8_t temp_buffer[BT_PROCESS_BUFFER_SIZE]; // 用于临时存储从环形缓冲区读取的数据
    rt_size_t read_len;

    // 从环形缓冲区中读取数据
    read_len = rt_ringbuffer_get(&uart3_rx_ringbuffer, temp_buffer, BT_PROCESS_BUFFER_SIZE);

    if (read_len > 0)
    {
        // 逐个字节地送入解析器
        for (rt_size_t i = 0; i < read_len; i++)
        {
            parse_byte(temp_buffer[i]);
        }
    }
}

void parse_byte(uint8_t byte)
{
    switch (current_state)
    {
        // 状态1: 等待 0xAA
        case STATE_HEADER1:
            if (byte == 0xAA) {
                current_state = STATE_HEADER2; // 收到，进入下一状态
            }
            break;

        // 状态2: 等待 0x55
        case STATE_HEADER2:
            if (byte == 0x55) {
                current_state = STATE_CMD; // 收到，进入下一状态
            } else {
                current_state = STATE_HEADER1; // 错误，重置回初始状态
            }
            break;

        // 状态3: 接收命令
        case STATE_CMD:
            packet.cmd = byte;
            current_state = STATE_LEN;
            break;
        // 状态4: 接收长度
        case STATE_WAIT_LEN:
            packet_len = byte;
            if (packet_len > 0)
            {
                data_index = 0;
                parser_state = STATE_WAIT_DATA;
            }
            else // 如果数据长度为0
            {
                parser_state = STATE_WAIT_CHECKSUM;
            }
            break;
        // 状态5: 接收数据
        case STATE_WAIT_DATA:
            packet_buffer[data_index++] = byte;
            if (data_index >= packet_len)
            {
                parser_state = STATE_WAIT_CHECKSUM;
            }
            break;
        // 状态6: 校验和验证
        case STATE_WAIT_CHECKSUM:
        {
            uint8_t checksum = 0;
            checksum += packet_cmd;
            checksum += packet_len;
            for (int i = 0; i < packet_len; i++)
            {
                checksum += packet_buffer[i];
            }

            if (checksum == byte) // 校验成功
            {
                // 一个完整的数据包接收并校验成功！
                handle_packet();
            }
            else
            {
                // 校验失败，可以在此打印错误信息
                my_printf(&huart1, "Checksum error!\n");
            }
            // 无论成功与否，都重置状态机，准备接收下一个包
            parser_state = STATE_WAIT_HEADER_1;
            break;

    }
}

它每次只处理一个字节，然后根据 current_state（当前状态）来决定下一步做什么。

switch-case 结构是实现状态机的绝佳方式，每个 case 就是一个独立的状态处理逻辑。

初始状态 (STATE_WAIT_HEADER_1):

• 状态机启动后，它唯一的目标就是等待协议的第一个包头 0xAA。
• 一旦接收到 0xAA，它就完成了第一个任务，并将状态切换到 STATE_WAIT_HEADER_2。

等待第二个包头 (STATE_WAIT_HEADER_2):

• 此时，期望接收到第二个包头 0x55。
• 如果成功接收到 0x55，说明包头匹配成功，状态切换到 STATE_WAIT_CMD，准备接收命令。
• 如果接收到的不是 0x55，说明这是一个错误的包（可能只是数据中恰好包含了0xAA），会立刻重置状态机回到 STATE_WAIT_HEADER_1。

接收命令和长度 (STATE_WAIT_CMD, STATE_WAIT_LEN):

• 将字节存入相应的变量 (packet_cmd, packet_len)，然后无条件地切换到下一个状态。
• 如果 packet_len 为 0，会直接跳过数据接收阶段，进入校验和状态 STATE_WAIT_CHECKSUM。

接收数据 (STATE_WAIT_DATA):

• 这是一个“循环”状态。它会一直留在这个状态，直到接收满 packet_len 个字节的数据。
• data_index 变量在这里起到了计数器的作用。每接收一个字节，data_index 就加一。
• 当 data_index 等于 packet_len 时，表示数据部分接收完毕，状态切换到 STATE_WAIT_CHECKSUM。

校验和验证 (STATE_WAIT_CHECKSUM):

• 根据已接收的 packet_cmd、packet_len 和 packet_buffer 中的数据，重新计算一遍校验和。
• 将计算出的 checksum 与接收到的最后一个字节 byte进行比较。
• 如果相等，校验通过！ 调用 handle_packet() 函数处理这个完整、正确的数据包。
• 如果不相等，说明数据在传输过程中发生了错误。
• 此时一个数据包的生命周期就结束了。状态机重置回 STATE_WAIT_HEADER_1，等待下一个数据包的到来。

3. 数据处理

当状态机成功接收并校验完一个完整的数据包后（在 STATE_CHECKSUM 状态完成），它会调用 handle_packet() 函数来执行真正的业务逻辑。

void handle_packet(void)
{
    switch (packet_cmd)
    {
        case CMD_SET_LED:
        {
            uint8_t led_status_data = packet_buffer[0]; // 数据在packet_buffer的第一个字节
            set_led_status(led_status_data); // 调用LED控制函数
            
            // 可以在这里回显调试信息
            my_printf(&huart1, "CMD_SET_LED received, status: 0x%02X\n", led_status_data);
            
            break;
        }

        case CMD_QUERY_LED:
        {
            uint8_t current_led_status = get_led_status(); // 获取当前LED状态
            send_response_packet(CMD_RESPONSE_LED, &current_led_status, 1); // 将状态打包回复
            
            // 调试信息
            my_printf(&huart1, "CMD_QUERY_LED received, responding with status: 0x%02X\n",current_led_status);
            break;
        }
        
        default:
            my_printf(&huart1, "Unknown CMD: 0x%02X\n", packet_cmd);
            break;
    }
}

改进

对于更复杂的、安全性要求更高的场景，可以作以下改进：

1. 增加超时机制

   如果只接受到半个包（例如，只发了包头和命令），状态机会永远停在中间状态（如 STATE_WAIT_LEN），无法自动复位。 增加一个超时定时器。在进入 STATE_WAIT_HEADER_2 时记录一下当前系统时间（例如 HAL_GetTick()）。在 BT_Task 的循环中，检查当前时间与记录时间的差值。如果超过了一个预设的阈值，就强制将 parser_state 复位到 STATE_WAIT_HEADER_1。

2. 数据长度校验

   如果错误地发送了一串超长的数据，超出缓存区发生溢出，导致数据丢失，程序出错。 在 STATE_WAIT_LEN 状态接收到 packet_len 后，立刻进行检查if (packet_len > BT_PROCESS_BUFFER_SIZE) ，若长度错误，重置状态机。

总结

有机会填上了“数据包解包/封包”这个之前一直想学却没深入的坑。

这次学习让我豁然开朗。“面条式” if-else 嵌套写法，在处理流式数据时会变得逻辑混乱、难以维护。

状态机的实现不仅让代码变得易于理解和扩展，并且很自然地实现了解析逻辑与业务逻辑的解耦。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/DevNotes/st7735s-driver-lcd-screen-development-notes

#define ST7735_IS_160X128 1

#define ST7735_WIDTH  128
#define ST7735_HEIGHT 160

#define ST7735_XSTART 2
#define ST7735_YSTART 1

#define ST7735_ROTATION (ST7735_MADCTL_MX | ST7735_MADCTL_MY | ST7735_MADCTL_RGB)

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/Sharing/github-edu-cert

看完了？说点什么呢

一个月之前在去哪儿网上预订了两晚酒店，结果昨天傍晚酒店方电联我，告知酒店因下暴雨被淹，不能入住，想让我主动取消，我当即就表达了不满，现在附近的订酒店均涨价许多，如果我取消，要自己承担涨价部分，酒店方在电话里居然还说“我们这边取消是要扣钱的，您取消我们没有损失”，这句话让我很恼火，要我当老好人吃亏，我肯定不能接受。 挂断电话，联系了平台维权，平台处理的很快，10分钟不到给我回了电话，告知我酒店确实不能接待，给我提出了一个赔偿方案:将原订单退款，并提供最高108元的差价补偿，也就是让我自己重新订酒店，新酒店订单价-原订单价 不超108元，都可以赔付。 我浏览了附近酒店的现价，发现这108元还是不能弥补涨价部分的损失，我没有同意上述方案，客服在10分钟后再次来电，这次补偿金额来到了最多400元，足以弥补差价，我最终接受了这个补偿方案。

《‌中华人民共和国民法典》第五百八十二条规定：履行不符合约定的，应当按照当事人的约定承担违约责任。对违约责任没有约定或者约定不明确，依据本法第五百一十条的规定仍不能确定的，受损害方根据标的的性质以及损失的大小，可以合理选择请求对方承担修理、重作、更换、退货、减少价款或者报酬等违约责任。根据以上规定，如果酒店未能按照约定提供服务，应承担违约责任。消费者可以要求酒店按照实际损失进行赔偿，包括但不限于额外住宿费用、交通费用等。 在这种情况下，一定要联系平台维权，平台提出的赔偿方案肯定有商量的余地，可以尽量争取一下更多的赔偿。

去哪儿网也对我这次赔偿提出了一些限定条件，需要注意一下

1. 所谓"三项"一致，即订房人，电话号码，订房城市
2. 订房日期一致
3. 需提交发票和订单信息截图

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/Game/blm-benchmark

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tanejo.cn/posts/WebsiteBuilding/cloudflare-r2-picgo-image-hosting

看完了？说点什么呢