当前位置： 首页 > news >正文

RISC-V开发板结合Python实现B站消息监测：硬件极客的IoT实践

news 2026/5/26 10:25:45

1. 项目概述：当硬件极客遇上日常痛点

前几天在极客社区里看到一个挺有意思的分享，一位开发者朋友用一块高性能的RISC-V开发板，结合自己写的Python脚本，做了一个B站未读消息的实时监测器。这项目乍一听有点“杀鸡用牛刀”的感觉——用一块能跑Linux的开发板去监测一个网页消息？但仔细琢磨，这恰恰是硬件创客精神的典型体现：用一个看似“过剩”的技术方案，去解决一个真实存在的、细小的生活痛点，并在过程中把玩技术、验证想法。

这个项目的核心逻辑并不复杂：通过Python脚本模拟浏览器行为，定期登录B站并抓取网页数据，解析出未读消息数量，最后通过开发板上的硬件接口（比如GPIO控制的LED灯、屏幕或者蜂鸣器）给出一个物理世界的提示。它解决的痛点很明确：对于重度B站用户，尤其是创作者或活跃社群参与者，频繁打开App或网页查看是否有新回复、新@或新私信，是一种注意力的碎片化干扰。这个设备可以让你在专注工作或学习时，无需分心查看手机或电脑，仅凭余光瞥一眼桌面上某个指示灯的颜色或闪烁频率，就知道“有事发生”。

从技术栈来看，它巧妙地串联了三个层面：应用层的网络爬虫与数据解析、系统层的Linux环境与定时任务、硬件层的物理交互与状态显示。选择RISC-V开发板而非更常见的树莓派或ESP32，除了性能足够流畅运行完整的Python环境及依赖库外，也带有一定的技术探索和社区支持考量。RISC-V作为开放指令集架构，其生态正在快速发展，用其开发板做这种贴近实际应用的小项目，本身就是对生态的一种实践和贡献。

对于想入门前端/后端与硬件结合（IoT雏形）、学习Python自动化脚本编写，或者单纯想给桌面增添一个有趣“赛博摆件”的朋友来说，这个项目有不错的复现价值。它不涉及复杂的电路设计，重点在于软件逻辑和系统集成，代码量不大，但完整走通后，你能掌握网络请求处理、HTML解析、Linux守护进程配置以及基础的硬件控制，是一个综合性很强的练手项目。

2. 核心思路与方案选型背后的考量

为什么是Python？为什么是RISC-V开发板？为什么用网页抓取而不是官方API？这些选择背后都有具体的权衡。

2.1 技术栈选型：Python + Requests + BeautifulSoup

首选Python是自然而然的。对于这种需要快速发起HTTP请求、解析HTML文本、处理JSON数据的自动化任务，Python的生态优势巨大。requests库让网络请求变得极其简单，BeautifulSoup或lxml是HTML解析的利器。整个脚本的核心逻辑可能在100行以内就能实现，开发效率极高。

为什么不直接用B站官方API？这是一个关键决策点。官方API通常需要申请复杂的OAuth2认证，涉及access_token的管理与刷新，对于个人小项目来说增加了不小的复杂度。更重要的是，API的权限控制严格，未必能直接获取到“未读消息总数”这个聚合信息。而通过模拟浏览器访问网页版个人空间，可以直接抓取到页面上显示的数字，虽然方式“原始”，但直达目标，且不需要处理令牌过期等问题，对于单用户、低频查询的场景更加简单粗暴有效。

当然，网页抓取的缺点是稳定性依赖B站前端页面结构。如果B站改版，选择器可能失效，需要更新脚本。但这对于学习项目而言，反而是一个优点——你学会了如何应对这种变化，如何定位元素，这本身就是一项实用技能。

2.2 硬件平台：为何选择高性能RISC-V开发板

很多人第一反应可能是用树莓派Zero W或者ESP32这类更普及、性价比更高的板子。这个项目选择一块能跑完整Linux发行版的高性能RISC-V开发板，主要有几点考虑：

  1. 开发环境一致性：在x86电脑上开发调试Python脚本，可以几乎无缝地部署到同样运行Linux的RISC-V开发板上。依赖库（如requests,bs4）可以直接通过pip安装，环境配置简单。如果使用ESP32，则需要使用MicroPython或C/C++，开发环境和库的差异会带来额外的学习成本。
  2. 处理能力富余：解析HTML、处理网络请求虽然不重，但需要一个稳定的Python运行时和网络栈。高性能RISC-V开发板（例如基于平头哥玄铁C906内核的板子）通常配备数百MB甚至上GB的内存，运行一个轻量级Linux发行版（如Debian、Ubuntu Base）绰绰有余，保证了脚本长期稳定运行，不会因为内存不足而崩溃。
  3. 探索与学习价值：RISC-V是当前硬件领域的热点。使用其开发板进行实际项目开发，能让你直观感受RISC-V架构的软件生态，了解如何为一种新架构交叉编译或直接安装软件包，这本身就是宝贵的经验。
  4. 强大的外设与扩展能力：这类开发板通常具备丰富的GPIO、USB、以太网/Wi-Fi接口，未来可以轻松扩展传感器、屏幕、语音模块等，将本项目升级为一个功能更丰富的桌面信息终端。

注意：如果你手头没有RISC-V开发板，用树莓派3B/4B、香橙派等任何能运行Linux的ARM开发板完全可行，整体方案和步骤几乎一致。选择RISC-V更多是“玩”的成分和面向未来的考量。

2.3 整体架构设计

项目的架构非常清晰，是一个典型的“感知-处理-执行”循环：

  1. 感知层（Python脚本）：定期执行，负责从B站网页抓取未读数量。
  2. 处理层（Linux Crontab/Systemd）：作为调度器，定时触发感知层脚本执行。
  3. 执行层（硬件接口）：根据脚本输出的结果，控制开发板上的物理设备（如LED、屏幕）改变状态。

这个架构的优点是模块化。你可以轻易替换其中任何一环。比如，把B站换成邮箱、GitHub通知；把LED提示换成在LCD屏幕上显示详情，甚至通过语音播报。

3. 核心脚本拆解与关键代码实现

让我们深入到Python脚本的核心部分。一个健壮的脚本不仅要能抓取数据，还要考虑异常处理、状态持久化和资源管理。

3.1 环境准备与依赖安装

首先，确保你的RISC-V开发板已经连接网络，并安装了基本的Python3和pip。通过SSH登录到开发板，进行以下操作：

# 更新软件包列表 sudo apt update sudo apt upgrade -y # 安装Python3和pip（如果尚未安装） sudo apt install python3 python3-pip -y # 安装必要的Python库 pip3 install requests beautifulsoup4 lxml

这里选择lxml作为BeautifulSoup的解析器，因为它比纯Python实现的html.parser速度更快，在资源有限的嵌入式环境里，这一点点性能提升也是有意义的。

3.2 模拟登录与会话维持

直接抓取个人页面需要登录状态。我们采用复用浏览器Cookie的方式，这是最简单且对服务器压力最小的方式。

第一步：手动获取Cookie。

  1. 在电脑上使用Chrome或Edge浏览器登录B站。
  2. 打开开发者工具（F12），切换到Network（网络）选项卡。
  3. 刷新一下个人主页（https://www.bilibili.com）。
  4. 在网络请求列表中，点击任意一个请求（通常是第一个www.bilibili.com的文档请求），在Headers（标头）选项卡中找到Request Headers（请求头）里的Cookie字段。
  5. 将其完整内容复制出来。它看起来像一串key=value;组成的字符串。

第二步：在脚本中使用Cookie。

import requests from bs4 import BeautifulSoup # 将你复制的Cookie字符串粘贴在这里 MY_COOKIE = 'your_cookie_string_here' headers = { 'User-Agent': 'Mozilla/5.0 (X11; Linux aarch64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36', 'Cookie': MY_COOKIE } def check_bilibili_unread(): url = 'https://www.bilibili.com' try: response = requests.get(url, headers=headers, timeout=10) response.raise_for_status() # 检查HTTP请求是否成功 # ... 后续解析代码 except requests.exceptions.RequestException as e: print(f"网络请求失败: {e}") return None

重要提示：Cookie是个人敏感信息，绝对不能将包含真实Cookie的脚本上传到GitHub等公开仓库。你应该将Cookie存储在环境变量或单独的配置文件中（如config.py），并在.gitignore中忽略该文件。在脚本中通过os.environ.get('BILI_COOKIE')来读取。

3.3 精准解析未读消息数量

登录后，B站首页或个人空间页面的HTML里，包含了未读消息的DOM元素。我们需要找到它并提取数字。由于B站前端可能动态渲染，直接查找静态HTML有时找不到。更可靠的方法是观察浏览器加载首页时发出的XHR（Ajax）请求。

  1. 打开浏览器开发者工具，登录B站后，停留在首页。
  2. 切换到Network选项卡，勾选Fetch/XHR过滤器。
  3. 刷新页面，你会看到一系列请求。寻找名称包含unread、message或feed的请求。
  4. 点击该请求，查看Preview（预览）或Response（响应）选项卡，通常是一个JSON格式的数据，里面清晰包含了未读私信、未读@、未读回复等具体数量。

假设我们找到了一个API端点返回JSON数据，例如：

{ "code": 0, "data": { "unread_private": 3, "unread_at": 1, "unread_reply": 5 } }

那么脚本的解析部分将变得非常简单和稳定：

import json def check_bilibili_unread(): api_url = 'https://api.bilibili.com/x/msgfeed/unread' # 示例URL，需实际查找 try: response = requests.get(api_url, headers=headers, timeout=10) data = response.json() if data['code'] == 0: unread_data = data['data'] total_unread = unread_data.get('unread_private', 0) + \ unread_data.get('unread_at', 0) + \ unread_data.get('unread_reply', 0) return total_unread else: print(f"API返回错误: {data['message']}") return None except (requests.exceptions.RequestException, json.JSONDecodeError) as e: print(f"获取或解析数据失败: {e}") return None

如果找不到清晰的API，退而求其次，还是得用BeautifulSoup解析HTML。你需要仔细分析页面元素，找到显示未读数字的那个<span>或<div>，通常它会有特定的class或id，比如.header-unread或#narrow-channel-unread。通过浏览器的“检查”功能可以定位到它。

def check_bilibili_unread_via_html(): url = 'https://www.bilibili.com' try: response = requests.get(url, headers=headers, timeout=10) soup = BeautifulSoup(response.content, 'lxml') # 这里需要根据实际页面结构调整选择器 # 例如，查找一个包含未读数字的span unread_element = soup.select_one('span.header-unread-count') if unread_element and unread_element.text.isdigit(): return int(unread_element.text) else: # 可能元素不存在或文本不是数字，返回0 return 0 except Exception as e: print(f"解析HTML失败: {e}") return None

3.4 状态持久化与变化检测

脚本不应该每次运行都无脑触发硬件提示。我们需要记录上一次的未读数，只有在新查询到的数字大于上一次记录时，才认为有“新消息”，触发提示。

import os import json STATE_FILE = '/tmp/bilibili_unread_state.json' def save_state(unread_count): """将当前未读数保存到文件""" with open(STATE_FILE, 'w') as f: json.dump({'last_count': unread_count}, f) def load_state(): """从文件加载上一次的未读数，如果文件不存在则返回0""" if os.path.exists(STATE_FILE): try: with open(STATE_FILE, 'r') as f: state = json.load(f) return state.get('last_count', 0) except (json.JSONDecodeError, IOError): return 0 return 0 def main(): current_unread = check_bilibili_unread() if current_unread is None: # 获取失败，本次不进行任何操作，也不更新状态 return previous_unread = load_state() if current_unread > previous_unread: print(f"发现新消息！当前未读: {current_unread}, 上次未读: {previous_unread}") # 这里调用函数触发硬件提示（例如点亮LED） trigger_hardware_notification(current_unread) # 更新状态 save_state(current_unread) elif current_unread < previous_unread: # 用户可能已经阅读了消息，更新状态即可 print(f"未读数减少，更新状态。当前: {current_unread}") save_state(current_unread) else: # 未读数未变化，无需操作 print(f"状态未变化，未读数: {current_unread}")

4. 硬件交互与状态提示实现

脚本获取到状态后，需要通过开发板的硬件接口给出反馈。这里提供几种常见且简单的方案。

4.1 方案一：GPIO控制LED灯（最基础）

这是最直观的方式。你可以使用一个双色LED（共阴极），或者两个单色LED（一个绿色代表“无新消息”，一个红色代表“有新消息”）。

接线示意图（以通用GPIO为例）：

  • LED1（绿色）阳极 -> 开发板GPIO引脚（如GPIO17） -> 串联一个220Ω电阻 -> 开发板GND。
  • LED2（红色）阳极 -> 开发板GPIO引脚（如GPIO27） -> 串联一个220Ω电阻 -> 开发板GND。

Python控制代码（使用RPi.GPIO库风格，不同板子库可能不同）：首先安装GPIO控制库，对于常见的WiringPi兼容或libgpiod的板子：

sudo apt install python3-gpiozero -y # 或者针对特定开发板安装对应的SDK

使用gpiozero库，它抽象得很好，代码简洁：

from gpiozero import LED import time green_led = LED(17) # 假设GPIO17接绿色LED red_led = LED(27) # 假设GPIO27接红色LED def trigger_hardware_notification(unread_count): if unread_count > 0: # 有新消息：红灯闪烁 red_led.blink(on_time=0.5, off_time=0.5, n=5, background=False) # 闪烁5次 green_led.off() else: # 无新消息：绿灯常亮 green_led.on() red_led.off()

gpiozero的blink方法非常方便，直接实现了闪烁效果，且background=False会让函数阻塞直到闪烁完成，适合作为提示。

4.2 方案二：使用OLED屏幕显示详情

如果你想让设备显示更多信息，比如具体的未读分类（私信、@、回复），一块I2C接口的OLED屏幕（如0.96寸SSD1306）是绝佳选择。

接线：

  • 屏幕VCC -> 开发板3.3V
  • 屏幕GND -> 开发板GND
  • 屏幕SCL -> 开发板I2C时钟引脚（如GPIO3）
  • 屏幕SDA -> 开发板I2C数据引脚（如GPIO2）

安装驱动库：

pip3 install luma.oled

Python显示代码：

from luma.core.interface.serial import i2c from luma.oled.device import ssd1306 from luma.core.render import canvas from PIL import ImageFont import time # 初始化I2C和OLED设备 serial = i2c(port=1, address=0x3C) # port根据板子I2C总线号调整 device = ssd1306(serial) # 尝试加载字体，如果没有就使用默认字体 try: font = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf', 12) except: font = None def display_message(unread_private, unread_at, unread_reply): with canvas(device) as draw: draw.rectangle(device.bounding_box, outline="white", fill="black") draw.text((5, 5), "B站未读消息", fill="white", font=font) draw.text((5, 20), f"私信: {unread_private}", fill="white", font=font) draw.text((5, 35), f"@我: {unread_at}", fill="white", font=font) draw.text((5, 50), f"回复: {unread_reply}", fill="white", font=font) # 显示一段时间后清屏，或者常驻显示 # time.sleep(10) # device.clear() # 在你的主逻辑中，当检测到状态变化时调用 # display_message(3, 1, 5)

4.3 方案三：结合蜂鸣器与LED（多感官提示）

对于需要强提醒的场景，可以加入一个有源蜂鸣器。当发现新消息时，让LED闪烁的同时，蜂鸣器也短促响几声。

接线：

  • 蜂鸣器正极 -> GPIO引脚（如GPIO22） -> 串联一个1kΩ电阻（可选，保护GPIO）-> 蜂鸣器负极 -> GND。

控制代码：

from gpiozero import Buzzer buzzer = Buzzer(22) def trigger_hardware_notification_with_sound(unread_count): if unread_count > 0: red_led.blink(on_time=0.3, off_time=0.3, n=6, background=False) # 蜂鸣器同步发声 for _ in range(3): buzzer.on() time.sleep(0.1) buzzer.off() time.sleep(0.1) green_led.off() else: green_led.on() red_led.off() buzzer.off()

5. 系统集成与后台常驻运行

脚本写好了，硬件也连好了，下一步是让它作为一个“服务”在开发板上24小时不间断运行。

5.1 使用Systemd创建守护进程（推荐）

这是最规范、最可靠的方式。Systemd可以管理进程的启动、停止、重启以及日志。

  1. 创建服务单元文件：

    sudo nano /etc/systemd/system/bilibili-monitor.service

  2. 编辑服务文件内容：

    [Unit] Description=Bilibili Unread Message Monitor After=network.target [Service] Type=simple User=pi # 替换为你的用户名，如`debian` WorkingDirectory=/home/pi/bilibili_monitor # 替换为你的脚本所在目录 ExecStart=/usr/bin/python3 /home/pi/bilibili_monitor/monitor.py Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
    • User: 指定运行服务的用户，避免使用root。
    • WorkingDirectory和ExecStart: 修改为你的实际路径。
    • Restart=on-failure: 脚本异常退出时自动重启。
    • RestartSec=10: 重启前等待10秒。

  3. 启用并启动服务：

    sudo systemctl daemon-reload sudo systemctl enable bilibili-monitor.service # 开机自启 sudo systemctl start bilibili-monitor.service # 立即启动 sudo systemctl status bilibili-monitor.service # 查看状态

  4. 查看日志：

    sudo journalctl -u bilibili-monitor.service -f # 实时查看日志

5.2 使用Crontab定时任务（备选）

如果不想用Systemd，也可以用Crontab定时执行脚本。但这种方式无法实现“状态变化时立即触发硬件动作”，因为Crontab只负责定时执行，脚本内部需要自己判断状态变化。

  1. 编辑当前用户的Crontab：
    crontab -e
  2. 添加一行，例如每5分钟执行一次：
    */5 * * * * /usr/bin/python3 /home/pi/bilibili_monitor/monitor.py >> /home/pi/bilibili_monitor/cron.log 2>&1
    这行命令表示每5分钟执行一次脚本，并将输出（包括错误）追加到日志文件中。

Systemd vs Crontab：对于本项目，强烈推荐Systemd。因为Systemd服务是常驻的，你可以让脚本内部包含一个循环，实现更灵活的检测间隔（比如每分钟检测一次），并且能更好地管理资源依赖（网络就绪后才启动）。Crontab适合执行独立、短时间的任务。

6. 项目优化与扩展思路

一个基础版本完成后，可以从以下几个方向进行优化和扩展，让项目更实用、更健壮。

6.1 提升脚本健壮性

  1. Cookie自动刷新：网页Cookie会过期。可以编写一个辅助脚本，模拟登录流程获取新Cookie，并自动更新配置文件。这涉及处理验证码，复杂度较高。一个更简单的方案是设置一个较长的Cookie过期提醒，手动更换。
  2. 双保险解析策略：同时尝试API和HTML解析。优先使用API，如果API失败或返回格式不符，则降级到HTML解析。提高容错率。
  3. 添加网络检查与重试机制：在发起请求前，先检查网络连通性。请求失败时，进行指数退避重试。
  4. 结构化日志：使用Python的logging模块替代print，可以输出不同级别的日志（INFO, WARNING, ERROR），并配置日志轮转，方便后期排查问题。

6.2 丰富硬件交互形式

  1. 多级提示：根据未读消息的数量级，设计不同的提示强度。例如：
    • 1-5条：绿灯慢闪。
    • 6-20条：黄灯快闪。
    • 20条以上：红灯闪烁并伴随蜂鸣。
  2. 加入物理按钮：添加一个按钮，按下后可以在OLED屏幕上轮播显示最新的几条消息摘要（需要解析更多API），或者一键标记所有消息为已读（通过模拟点击网页或调用API）。
  3. 远程通知：结合开发板的网络能力，当检测到新消息时，除了本地硬件提示，还可以通过Telegram Bot、Server酱、钉钉机器人等将通知推送到你的手机。

6.3 平台与功能扩展

  1. 多平台聚合：将脚本改造成一个通用的“网络消息监测器”。除了B站，还可以加入GitHub通知、邮箱未读、论坛私信等。为每个平台写一个插件化的检查函数，主程序轮询所有插件。
  2. 数据可视化与历史记录：将每次检查的未读数量和时间戳记录到SQLite数据库中。然后写一个简单的Flask或FastAPI web服务跑在开发板上，通过浏览器访问一个本地网页，可以看到未读消息数量的历史趋势图。
  3. 语音播报：接入一个USB麦克风或语音合成模块（如SYN6288），当有新消息时，用语音播报“您有新的B站消息”。

7. 常见问题与故障排查实录

在实际部署和运行中，你几乎一定会遇到下面这些问题。

7.1 网络请求失败或返回异常数据

  • 现象：脚本报错requests.exceptions.ConnectionError或返回的数据不是预期的JSON/HTML。
  • 排查：
    1. 检查网络：在开发板上执行ping www.bilibili.com，看是否能通。
    2. 检查Cookie：Cookie可能已过期。手动在浏览器访问B站，看是否仍处于登录状态。重新获取Cookie并更新脚本。
    3. 检查User-Agent：有些网站会屏蔽一些非常见的User-Agent。确保你的User-Agent字符串是常见的浏览器标识。
    4. 打印响应内容：在脚本中临时添加print(response.text[:500])，查看服务器返回的实际内容是什么。可能是反爬虫页面（如验证码），也可能是页面结构已变更。
  • 解决：更新Cookie，调整请求头，或根据新的页面结构修改解析代码。

7.2 GPIO控制无反应，LED不亮

  • 现象：脚本运行无报错，但LED灯没有任何反应。
  • 排查：
    1. 检查接线：这是最常见的问题。确认LED的正负极没有接反，电阻已正确串联，GPIO引脚号在代码和物理连接上是否一致。
    2. 检查电压：用万用表测量GPIO引脚在输出高电平时是否有电压（通常是3.3V）。有些引脚默认功能可能不是GPIO，需要先配置。
    3. 检查库和权限：运行GPIO控制通常需要root权限或用户加入gpio组。使用sudo运行脚本测试，或者将当前用户加入相关硬件访问组（如sudo usermod -a -G gpio $USER，然后重新登录）。
    4. 查看系统日志：运行dmesg | tail，看看是否有关于GPIO的错误信息。
  • 解决：纠正接线，确认引脚编号，使用正确的权限运行脚本。对于gpiozero库，它通常会自动处理权限和引脚映射，问题多出在硬件连接。

7.3 Systemd服务启动失败

  • 现象：sudo systemctl status bilibili-monitor.service显示状态为failed或inactive。
  • 排查：
    1. 查看详细日志：sudo journalctl -u bilibili-monitor.service -n 50查看最近50行日志，错误信息通常在这里。
    2. 检查路径和权限：确保WorkingDirectory和ExecStart中的路径存在且可执行。确保User指定的用户有该目录的读取和执行权限。
    3. 检查Python依赖：服务是在系统环境下运行的，可能缺少Python库。尝试在服务指定的WorkingDirectory下，以对应用户身份手动执行python3 monitor.py，看是否报错。
    4. 检查环境变量：有时脚本依赖某些环境变量（如PATH）。可以在[Service]部分添加Environment指令来设置，或者直接在脚本中使用绝对路径。
  • 解决：根据日志错误信息逐一修正。常见做法是先确保在命令行下能手动正常运行脚本，再调试Systemd配置。

7.4 资源占用与性能考量

  • 担忧：这个脚本会不会很耗电、占资源？
  • 分析：完全不必担心。一个简单的Python脚本，每分钟甚至每5分钟发起一次HTTP请求并做简单的文本解析，其CPU和内存占用可以忽略不计。RISC-V开发板在空闲时功耗本身就很低。主要的资源消耗是网络流量，每次请求的流量在几KB到几十KB之间，对于现代网络环境来说微乎其微。
  • 优化建议：可以将检测间隔调整到合理范围，比如5-10分钟一次，既能及时提醒，又不会对B站服务器造成不必要的压力。在脚本中增加随机延迟，避免所有用户都在整点请求。
http://www.jsqmd.com/news/845163/

相关文章：

  • 长期使用体验谈Taotoken平台API服务的稳定性与响应速度
  • 西安亦远建筑工程：西安靠谱的别墅庭院设计公司怎么联系 - LYL仔仔
  • 手滑发了二十几个品，我手动撤回点到手抽筋
  • 无王无帝定乾坤，来自田间第一人 一身正气开大道
  • 石家庄黄金回收避坑 石家庄黄金回收套路揭秘 石家庄黄金回收哪家不压价 石家庄黄金回收价格查询 石家庄街边收金骗局 - 润富黄金珠宝行
  • 新手学鸿蒙——02-UIAbility组件深度解析
  • 2026口碑好的硫化氢检测仪厂家，通常做对了这3件事 - 品牌推荐大师
  • python系列【仅供参考】：mongo4.0.0 加用户认证 motor和pymongo的auth连接
  • MASA全家桶汉化包：让Minecraft模组操作无障碍的中文解决方案
  • Figma设计文件与JSON格式双向转换技术方案解析
  • 深度解析New API：企业级AI模型网关实战部署与成本优化指南
  • 从DVWA靶场看Web安全：一个漏洞的四种防御等级，你的代码在第几层？
  • 跟着豆包学AI第二天（Windows版本）
  • 别再手动改hosts了！用Docker Compose一键部署Authelia SSO，顺便搞定Traefik反向代理
  • 后浪教育90+就业率：平面设计首选，直接对接商单 - 博客万
  • 2026年全自动搅拌桩机等搅拌设备厂家推荐：郑州川禾机械设备有限公司，全自动搅拌机后台/搅拌机桩机后台专业选型指南 - 品牌推荐官
  • 如何为你的直播添加实时字幕？OBS字幕插件完全指南
  • QQ音乐解析工具终极指南：如何轻松获取全网音乐资源
  • 专业的成都儿童摄影底片全送服务好
  • 双层玻璃反应釜采购指南：从参数到品牌的深度拆解 - 品牌推荐大师
  • 从 VS Code 转战 JetBrains？WebStorm/PyCharm 用户迁移 GitHub Copilot 的完整避坑指南
  • 2026年降AI工具处理摘要结论专项测试：五款工具摘要结论高AI率段落处理效果完整横评 - 还在做实验的师兄
  • 2026年重庆自助KTV加盟与24小时K歌消费全景指南：声艺大咖如何用轻资产模式颠覆传统娱乐业 - 精选优质企业推荐官
  • 告别SSH断连烦恼：用Tmux在服务器后台挂程序，保姆级配置教程（含Mac本地安装）
  • Agent 工程化系列 · 第 16 篇_Agent 项目为什么经常失败？不是模型不够强，是工程没设计好
  • 妹妹用这个
  • 终极窗口隐身术：3分钟学会用Boss-Key打造你的数字安全区
  • 知网AIGC检测系统机制深度解读：2026年知网检测算法特点与免费应对完整分析 - 还在做实验的师兄
  • 2026年降AI工具知网检测专项实测：五款主流工具知网AIGC检测通过率完整横评 - 还在做实验的师兄
  • 浩卡平台邀请码多少？2026最新用户口碑解析 - 博客万