news 2026/10/6 9:09:03

Python+Selenium实现LinkedIn自动连接,HR人脉拓展效率翻倍

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Python+Selenium实现LinkedIn自动连接,HR人脉拓展效率翻倍

先问一个问题:有多少HR、销售、猎头,每天打开网页版职场社交平台,搜索完目标人群,然后对着候选人头像一个一个点“连接”?我认识的一位招聘经理,每天给自己定的KPI是新增30个有效联系人,手动操作大概要一个多小时,中间还要被各种会议打断。后来他把这件事交给Python脚本,每天早上到公司后脚本自动跑一轮,他去开晨会,回来查看结果,只处理真正需要人工跟进的消息。这个变化对我来说很触动,因为手动操作这件事本身价值很低,但消耗的时间非常致命。

这篇文章我打算从一个实际可运行、可修改的Python脚本切入,讲讲如何用Selenium控制浏览器完成登录、搜索、批量发送连接邀请的全流程。会涉及技术选型的思考、具体的代码实现、防封号的一些细节,还有我实际操作中踩过的坑。不管你是HR、业务负责人,还是和我一样写Python的人,只要目标人群在LinkedIn这类平台上,这套思路都完全能迁移。

1. 先搞清楚:HR为什么需要这个脚本

1.1 传统人脉拓展的痛点在哪

LinkedIn不只是一个简历库,它更像一个带着实时动态的行业通讯录。HR在LinkedIn上找人,核心动作其实高度重复:搜索目标关键词(比如“产品经理 电商”、“人力资源总监 快消”)、浏览搜索结果、查看候选人档案、判断是否值得建立联系、发送连接邀请。整套动作里,真正需要人工判断的部分大概是20%,剩下80%都是机械操作。

我说一个真实场景。某互联网公司HR要招一个资深数据分析师,目标候选人在三家知名企业或者若干初创团队。她手动搜索关键词“Data Analyst”,一页一页翻,一个一个加。加了80个人之后,眼睛花了,手也酸了,还会重复点击已经发送过邀请的人,并且她发现LinkedIn限制每周连接数之后,她不知道哪些人加了,哪些没加,全靠记忆,最后还得开个Excel表自己记。这件事的本质不是她不认真,而是工具不行,人做重复点击的效率上限,和写脚本做自动化的效率差距是数量级上的。

再看另一面。人脉拓展还有一个隐藏痛点:时机。候选人看到HR发来的连接邀请,一般不会立刻通过,但一个规范的邀请语能显著提高通过率。手动操作模式下,你很难保证每一次邀请语都一样规范且专业,发送时间也无法统一。脚本能把发送频率控制在合理的节奏内,把邀请语统一格式,还能自动跳过已经发过连接邀请的人,这件事人工操作起来特别容易遗漏。

1.2 这个脚本具体能解决什么

我用一个Python实用小脚本来解决这个需求,具体它能做什么:

  • 自动完成登录流程,包括处理“保持登录状态”之类的选项。
  • 输入关键词搜索目标人群,限定地区、行业等维度。
  • 逐条读取搜索结果,判断对方是否已经建立过连接(已经是好友的会显示“已连接”)。
  • 对未连接且符合条件的人发送带有个性化备注的连接邀请。
  • 自动记录已发送邀请的名单,后续手动跟进时直接导入。
  • 控制发送速度和每天的发送量,避免触发反滥用机制。

这个脚本的应用对象虽然是LinkedIn,但核心逻辑是通用的。任何需要登录、搜索、批量操作的外部平台,只要理解了这个套路,都能改造出来一套自己的自动化工具。

1.3 适合谁看,能收获什么

如果你是HR,主要收获是时间。以后再也不用把下午三个小时全部耗在加人上,脚本可以放在午饭前或者下班前执行,你把精力花在已经通过连接申请的候选人对话上。

如果你是Python初学者,这篇文章是一个典型的“学完基础语法就能跟”的实战项目。它用到了Selenium的元素定位、显式等待、异常处理、随机延时、配置管理,跟着写一遍,你对网页自动化的理解会上一个台阶。

如果你是技术负责人,这篇文章的重点不在脚本本身,而在于如何规范地把自动化能力封装成一个可维护的小工具,比如把账号密码放进环境变量、把关键词参数化、输出结构化日志。这些习惯对后续任何自动化项目都有价值。

2. 技术选型:为什么是Selenium而不是Axios或Playwright

2.1 先排除的方案:requests直连API

很多人一听到自动化,第一个想法是用Python的requests包直接调接口。LinkedIn这类平台的移动端或者网页端确实有接口,但这些接口通常有签名机制,需要动态生成某些header字段,而且会话token的有效期很短,还要处理CSRF token、登录后的cookie校验等。最关键的是,接口随时可能变动,一旦变了你写的代码基本就作废,维护成本极高。对于个人工具来说,这个方案投入产出比太差,我不推荐。

2.2 再比较:Playwright vs Selenium

最近两年Playwright很火,它的优点是对现代前端框架的适配性更好,自动化等待逻辑更智能。那为什么我这里用Selenium,原因有三个:

第一,Selenium的用户群体更大,遇到问题搜索解决方案更容易,Stack Overflow上的历史答案足够多。第二,Selenium WebDriver支持的语言范围广,如果你想用Java或C#改造,学习曲线基本是平的。第三,WebDriver几十年来形成的生态非常稳,虽然启动慢一点,但在这种慢速操作的场景(每条邀请之间还要随机等待几十秒)下,启动性能差异根本感觉不到。

2.3 最终采用的组合:Selenium + Python

所以我最终选定的组合是Python 3.10以上 + Selenium 4.x + WebDriver Manager + Chrome浏览器。核心代码如下:

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service import random import time

WebDriver Manager这个库强烈建议用,它会自动匹配当前Chrome版本并下载对应的ChromeDriver,省掉你手动配置driver路径的环节。以前我用Selenium最痛苦的一件事就是Chrome自动更新后driver版本不匹配,现在这个问题彻底消失了。

2.4 登录方式的选择逻辑

登录LinkedIn有两种方式:一种是用账号密码自动登录,另一种是用已经存在的登录状态(即手动登录过、保留cookie后脚本复用浏览器的用户目录)。我强烈推荐第二种。

用账号密码自动登录听起来完美,但实际使用时有两个大问题:一是LinkedIn的风控对异常登录很敏感,如果同一个账号频繁在不同环境登录,很容易触发验证码甚至临时限制;二是密码管理本身就是安全风险。所以我的做法是:第一次自己手动在浏览器里登录一次,然后把该浏览器的用户数据目录作为参数传给Selenium,这样脚本运行时天然带着登录态,不需要重新输密码,也不需要处理验证码。

这个方案唯一的代价是你需要找到Chrome的用户数据目录,Windows一般在C:\Users\你的用户名\AppData\Local\Google\Chrome\User Data,macOS在~/Library/Application Support/Google/Chrome/。传给Selenium时要注意用user-data-dir参数指向这个目录的上一级,而不是整个目录,避免浏览器启动时锁冲突。

options = Options() options.add_argument("--user-data-dir=/path/to/Chrome/User Data")

user-data-dir指向的是User Data那一层,Chrome会自动识别下面的Default文件夹。另外还有一种做法是用user-data-dir指向一个新的空目录,先手动登录一次,之后脚本每次都用这个目录,相当于给脚本开了一个独立的登录环境,不会影响你日常浏览器的登录态,我实际测试这个方案更干净。

3. 完整实操:从环境准备到跑通第一轮自动连接

3.1 环境准备与依赖安装

开始写代码之前,你首先确保本机有Python环境,版本建议3.10以上。没装Python的话去官网下载安装包,安装时记得勾选“Add Python to PATH”。装完之后在命令行确认:

python --version

然后安装依赖:

pip install selenium webdriver-manager pandas

有的环境可能会出现安装慢的情况,可以换成国内镜像源安装,但具体镜像源我这里就不展开了,你根据自己的网络情况选一个顺手的。

这里补充一个技巧,建议用虚拟环境,不要直接装到全局环境。用python -m venv venv创建虚拟环境,之后激活再安装依赖。这样你换电脑或者迁移项目的时候,一条pip freeze > requirements.txt就能带走所有依赖,别人复现起来也方便。

3.2 参数配置:把不常变的量集中管理

脚本里有很多参数需要经常调整,比如搜索关键词、地区、发送条数上限、延时范围等。不要把这些值硬编码在代码里,而是集中放在一个配置区,方便改。比如:

CONFIG = { "search_url": "https://www.linkedin.com/search/results/people/?keywords=人力资源总监&geoUrn=%5B%221010902%22%5D", "max_invites": 20, # 本轮最多发送连接邀请数量 "min_delay": 35, # 最小延时(秒) "max_delay": 75, # 最大延时(秒) "note_template": "您好,我是XX公司HR,专注互联网行业高端岗位招聘,希望与您保持联系,未来可能有合作机会。", }

geoUrn这个参数其实是LinkedIn搜索URL里的地理位置编号,代表特定地区,你可以先去网页上手动搜索一次,然后把浏览器地址栏里的URL复制过来直接用。这样做比用Selenium去点击筛选器要稳定得多,因为页面上筛选器的DOM结构变化频繁,而URL参数相对稳定。

3.3 核心代码模块拆解

整个脚本我拆成三个函数:

第一个函数build_driver是启动浏览器。关键设置包括:指定用户数据目录、禁止自动化提示、可选无头模式。

def build_driver(): options = Options() options.add_argument("--user-data-dir=/tmp/linkedin_profile") options.add_argument("--disable-blink-features=AutomationControlled") # 如果想在后台运行,取消下面这行注释 # options.add_argument("--headless=new") service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service, options=options) driver.maximize_window() return driver

disable-blink-features=AutomationControlled这个参数值得单独说一下。Selenium的默认状态会被网站识别为自动化工具,很多平台对自动化操作监控比较紧,隐藏这个特征能降低被识别的概率。但这不是什么万能的方案,别过度依赖。

第二个函数send_invite是核心。逻辑是:打开搜索页,等待结果加载完成,逐条查看结果,找到“连接”按钮就点击,点击后弹窗出现,填写个性化备注,然后发送。

def send_invite(driver, url, max_invites): driver.get(url) sent_count = 0 wait = WebDriverWait(driver, 15) while sent_count < max_invites: connect_buttons = driver.find_elements(By.XPATH, "//button[contains(@aria-label, '邀请') or contains(@aria-label, 'Connect')]") if not connect_buttons: break for btn in connect_buttons: if sent_count >= max_invites: break try: driver.execute_script("arguments[0].scrollIntoView(true);", btn) time.sleep(2) btn.click() # 等待弹窗出现“添加备注”按钮 add_note = wait.until(EC.element_to_be_clickable((By.XPATH, "//button[contains(@aria-label, '添加备注')]"))) add_note.click() # 填写备注 note_area = wait.until(EC.presence_of_element_located((By.XPATH, "//textarea[@id='custom-message']"))) note_area.send_keys(CONFIG["note_template"]) # 点击发送 send_btn = driver.find_element(By.XPATH, "//button[@aria-label='发送邀请']") send_btn.click() sent_count += 1 print(f"[成功] 已发送第 {sent_count} 条邀请") delay = random.uniform(CONFIG["min_delay"], CONFIG["max_delay"]) time.sleep(delay) except Exception as e: # 弹窗可能没出现,尝试关掉弹窗继续 try: cancel = driver.find_element(By.XPATH, "//button[@aria-label='关闭']") cancel.click() except: pass print(f"[跳过] 处理失败:{e}") time.sleep(5) return sent_count

这里有几个细节非常关键。

第一个细节:为什么用execute_script滚动到元素?LinkedIn的结果页会做懒加载,屏幕外的元素如果不在视口内,Selenium的点击操作会报“element not interactable”异常。先手动滚动到目标元素,让它触发加载,再点击,成功率会高很多。

第二个细节:为什么点击“连接”后要等弹窗?LinkedIn的连接按钮点击后不一定会立刻弹窗,有时候它直接发送了(如果你没有开启需要备注的选项),所以要等弹窗元素出现,再去做后续的备注填写。用WebDriverWait而不是time.sleep,是因为等待时间不确定,显式等待能自动判断。

第三个细节:异常处理时为什么尝试点关闭?如果某个按钮点击没触发弹窗,而是一个其他的弹层,比如“本月已达上限”的提示,你还在傻傻等“添加备注”按钮,那就会超时。捕捉异常后先尝试点关闭,如果关闭按钮也不存在,就跳过继续下一个。这种防御式写法在自动化脚本里非常实用,宁可多写几行异常处理,也不要让程序卡死。

第三个函数main是调度函数,负责启动浏览器,执行发送,完成后退出。

def main(): driver = build_driver() try: driver.get("https://www.linkedin.com/feed/") time.sleep(5) # 如果页面跳转到登录页,说明登录态失效,给出提示并退出 if "login" in driver.current_url: print("登录态已失效,请手动登录一次后再运行脚本") return count = send_invite(driver, CONFIG["search_url"], CONFIG["max_invites"]) print(f"本轮执行完毕,共发送 {count} 条连接邀请") finally: driver.quit()

3.4 运行与调试

主逻辑完成后,直接跑python linkedin_invite.py即可。建议第一次不要设置太大的max_invites,设成5条,先观察一遍流程跑不跑得通。我第一轮写脚本时,就遇到wait.until等待“添加备注”按钮一直超时,最后发现是点击“连接”按钮后,页面又出现了一个确认弹窗,需要再点一次“现在发送”之类的按钮。这种问题只有实际跑起来才能发现,不要怕报错,报错信息就是你的调试线索。

日志方面,我会在控制台直接打印每一条的状态。如果想留档,可以改成或同时写入一个log.csv,记录发送时间、目标岗位关键词、结果状态。数据积累多了以后,你自己就能看出哪个岗位的关键词转化率更高,哪个时间段的连接通过率更优。

4. 踩坑记录:自动连接遇到的高频问题与排查思路

4.1 登录态失效了怎么办

场景:脚本跑着跑着突然弹出登录页,或者直接跳转到登录页面,这通常是因为LinkedIn服务端升级导致原有会话失效。解决办法:手动打开浏览器,使用你传给Selenium的那个用户数据目录登录一次,之后脚本自动复用这个新的登录态。

排查技巧:每次启动脚本后马上检查driver.current_url是否包含login或authwall。如果包含,立即停止执行,不要让它带着登录态去操作,否则可能出现批量点击未登录按钮的无意义动作。

4.2 Selenium定位不到按钮

这种问题出现的频率最高。LinkedIn的DOM结构里,很多按钮的文案和aria-label是动态的,中文登录环境下显示“连接”,英文环境下显示“Connect”,还有“邀请”和“Follow”混在一起,一不小心就会把“关注”按钮当成“连接”按钮,导致发出去的并不是连接邀请。

我的建议是:用aria-label配合contains做模糊匹配,不要用精确匹配。上面代码里我用的是contains(@aria-label, '邀请') or contains(@aria-label, 'Connect'),这样中文英文都能覆盖。如果后期LinkedIn改了文案,优先用浏览器开发者工具检查该元素的aria-label实际值是什么,更新XPATH即可。

还有一个实用技巧:优先用XPath而不是CSS Selector。原因很简单,LinkedIn的CSS类名经常是随机生成的字符串,比如artdeco-button__primary这种还算稳定的,有时候是artdeco-button--3这种带数字后缀的,很容易变。而aria-label这种属性是给无障碍用户用的,一般不会乱改。

4.3 发送连接邀请被限制

这是最重要的一条坑。LinkedIn对连接邀请有明确的数量控制,新账号每周的连接请求上限大约是100个左右,滥用会导致账号被限制。我被限制过一次,那次的教训是:设置max_invites=50,以为没问题,但前一天手动操作已经发过不少邀请了,脚本又发了50条,直接触发了风控,账号被临时限制发送连接邀请一周。

解决方案:

  • 每周发送数量控制在40-60条以内,保守优先。
  • 每次发送之间加随机延时,35到75秒之间随机取,人为模拟真实操作节奏。
  • 不要同时开多个标签页并行操作,一个浏览器窗口顺序操作最安全。
  • 如果发现某条邀请发送后弹窗提示“本月已达上限”或类似文案,立刻停止脚本,这周再跑就是找封号。

4.4 无头模式运行不稳定

无头模式(headless=new)适合挂在服务器上跑,但在LinkedIn这种重度反自动化站点上,它更容易被识别。我的经验是:如果只是在自己电脑上跑,就用普通模式,窗口最小化即可,没必要为了一点资源浪费去冒险。除非你有完整的服务器部署方案,否则无头模式带来的风控风险大于便利。

4.5 网页弹窗卡住了脚本

页面偶尔会出现“确认两端设备同时登录”的提示,或者一个安全验证弹窗,这种时候脚本如果没有对应处理,就会卡在等待某个元素上。我的建议是:在主循环外面再加一个保护逻辑,检测页面是否出现了意料之外的弹窗元素,如果出现直接截图+关闭弹窗+记录日志,然后再继续。

def safe_driver_get(driver, url): driver.get(url) time.sleep(3) try: unexpected = driver.find_element(By.XPATH, "//*[contains(text(), '确认这是你') or contains(text(), '验证')]") if unexpected: # 截图留证 driver.save_screenshot("unexpected_popup.png") print("发现意外弹窗,已截图") except: pass

这里最重要的是截图留证。以后即使账号被限制,你也能拿出证据说明你当时看到了什么界面,方便自己复盘到底是操作频率太高,还是某个弹窗误导了脚本。

5. 重要提醒:别让脚本毁了你的LinkedIn账号

5.1 平台规则与职业伦理的边界

写自动化脚本的目的应该是“辅助人做更有价值的事”,而不是“替代规则、绕过限制”。LinkedIn在用户协议里明确禁止使用未授权的自动化工具访问其服务。所以这篇文章里的脚本,我定位是学习型、低频率辅助型工具,不是用来批量骚扰陌生人的。

实际操作中,我在脚本里强制设置了每周最多发送60条的硬编码上限,超过直接拒绝执行。这不是技术限制,这是底线。人脉拓展的本质是建立信任,信任的前提是每一步沟通都是基于人的真实意图。如果脚本帮你发出了几千条邀请,请问候选人通过之后,你有精力跟每个人深入聊吗?没有精力,那邀请本身就没有价值。

另外还要注意隐私和合规。发送的个性化备注里不要包含对方的姓名或公司信息,因为脚本无法保证最新数据与页面展示完全一致,一旦备注里写错公司名或职位,对方对你的专业度会有很大怀疑。我的策略是用一个通用但真诚的模板,强调“希望保持联系”和“未来可能有合作机会”,而不是编造细节。

5.2 账号安全是底线

千万不要把你的账号密码明文写在脚本里。用user-data-dir方案永远比账号密码方案安全,因为你的登录态以cookie形式存储在本地,不进内存、不进代码、不进日志。如果你实在要用密码方案,至少用os.environ.get("LINKEDIN_PASSWORD")从环境变量读取,不要把值直接贴在代码提交到Git仓库。GitHub上很多人因为不小心把密码提交到公共仓库,然后账号被盗用,那真是血的教训。

还有一点,用user-data-dir时注意目录权限。如果用的是临时目录,里面的登录态是全新的,登录一次后该目录会保存所有会话数据。不要把临时目录放在/tmp这种可能被其他用户读写的路径下,放在自己用户目录下的隐藏文件夹即可。

5.3 自动化之前先问自己三个问题

很多HR看到这类脚本会兴奋,但我建议你先回答三个问题再动手:

  • 我的目标人群对这个平台的使用频率有多高?如果目标人群集中在行业社群或线下活动,闷头加人的效率远不如定向参加几次会议,脚本就帮不上忙。
  • 我有没有精力承接自动化带来的连接通过后续交流?如果每周通过50条连接,但没有能力跟进,那这些连接只是数字,对你的招聘和职业发展没有实际助力。
  • 我是否愿意投入时间维护这个脚本?平台改版会定期发生,脚本也需要持续更新。如果没有意愿长期维护,不如只把自动化用在搜索和数据收集上,发送动作保留手动。

以我个人的经验,很多HR最终把脚本定位成“自动收集+筛选候选人”,真正发送邀请前还是要自己过目一遍,因为你的职业声誉经不起“群发骚扰”这种标签。这个平衡你要提前想清楚。

5.4 后续还能怎么扩展

这套脚本的逻辑完全可以扩展到其他场景。比如用同样的登录态,写一个定时监控脚本,每天早上把某个关键词下新出现的潜在联系人汇总成报告发送到邮箱;还可以用Pandas对搜索结果的姓名、职位、公司做结构化解析,生成可检索的人脉表格;更进阶一点,用Selenium模拟浏览候选人主页,记录对方最近发布的动态,作为后续沟通的切入点。

如果你有多个招聘方向,可以做成多关键词的循环任务。先扫描关键词列表,对每个关键词发送少量连接邀请,轮询一轮后再开始下一轮,这样既分配了配额,又不会引起风控。代码层面你需要做的只是把CONFIG["search_url"]换成关键词列表的循环。

5.5 最后补充一点调试技巧

所有Selenium脚本的调试,核心就是四个字:看页面状态。页面在跑什么、脚本在等什么、元素有没有出现,这些如果你不亲眼看见,光靠日志很难判断。所以调试阶段强烈建议不要用无头模式,不要最小化窗口,让浏览器肉眼可见地跑起来。等你确认完整流程稳定后,再决定要不要把它改成后台任务。

写在最后

我最初写这套脚本是因为一位做猎头的朋友每天都得加人,加到怀疑人生,后来这个工具帮她每周省出大半天时间去做真正的深度沟通。这件事让我意识到,所谓的“工具效率”,核心不在于人要变得更忙,而是要把时间从低价值重复动作中解放出来。LinkedIn自动连接只是一个具体的场景,它背后通用的逻辑是:凡是重复的、规则明确的、不太需要判断的操作,都可以用代码帮你完成;凡是涉及建立信任、展现专业度的动作,请务必留给人来做。

如果你已经理解了这个思路,建议先不要贪多,就用我上面的代码框架,设一个5条的上限跑一天试试。跑通了,你会觉得自动化很有成就感;跑失败,也没关系,报错信息就是最好的老师,修一修,又是一套属于你自己的实用工具。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/6 9:08:40

OpenShell开放外壳环境:从概念到实战的运维自动化指南

1. 从一个空输入说起&#xff1a;为什么"OpenShell"值得单独写一篇拿到这个标题的时候&#xff0c;项目正文、关键词、摘要描述全是空的&#xff0c;只有"OpenShell"这一个词&#xff0c;外加一条"相关热搜词&#xff1a;OpenShell"。这种输入状…

作者头像 李华
网站建设 2026/10/6 9:05:28

USC三大硬课Midterm复习:计算机网络、Java与Web全栈经验总结

开学的时候我还挺自信&#xff0c;觉得自己一个学期能同时搞定 USC 的 EE450、CSCI455 和 CSCI571&#xff0c;结果 midterm 前两周差点没把自己逼疯。这三门课在 USC 计算机和 EE 圈子里都是出了名的“工作量担当”&#xff1a;EE450 是计算机网络老牌硬课&#xff0c;CSCI455…

作者头像 李华
网站建设 2026/10/6 9:04:20

TMS320F28335 DSP代码从Flash到RAM的搬运与烧写实战

先把型号说准&#xff1a;TI没有TMS320FF28335这个型号&#xff0c;实际是TMS320F28335&#xff0c;标题里多半是手误多打了一个F。F28335是C2000家族里非常经典的一块DSP&#xff0c;Flash容量256K16&#xff0c;RAM却只有34K16&#xff0c;这种“大Flash、小RAM”的架构决定了…

作者头像 李华
网站建设 2026/10/6 9:04:17

Docker内网离线部署全流程指南:从镜像准备到生产实践

1. 为什么需要离线部署&#xff1a;一个让我凌晨三点爬起来改方案的场景大概半年前&#xff0c;接手了一个政府单位内部系统的迁移任务。网络环境属于典型的物理隔离内网&#xff0c;跟外网完全不沾边的那种。机器倒是不少&#xff0c;但所有服务器、工作站全部在一个封闭的网段…

作者头像 李华
网站建设 2026/10/6 9:04:13

STM32 CAN通讯过滤器寄存器详解:从配置到实战验证

做STM32的CAN通讯&#xff0c;十有八九会在过滤器这儿卡一下。我第一次调F103的bxCAN时&#xff0c;收发器、波特率、中断都配好了&#xff0c;发端数据照发&#xff0c;收端就是进不了接收中断。把过滤器关掉之后又反过来&#xff0c;总线上所有节点的帧全都涌进FIFO&#xff…

作者头像 李华
网站建设 2026/10/6 9:04:12

Qt 5.8.0三架构交叉编译实战:x64/x86/armhf与Cubietruck部署

开篇先交代一下背景。去年手上拿到一块Cubietruck&#xff08;就是那款全志A20双核的开发板&#xff09;&#xff0c;想在上面跑一套带界面的Qt应用&#xff0c;做一个小型的数据展示终端。A20是Cortex-A7核心&#xff0c;跑Debian系的armhf系统问题不大&#xff0c;但真正折腾…

作者头像 李华