2025-10-29 10:35:00

最近老T因为此前使用哪吒探针V0版时所需要的通信域名将要到期,于是选择对探针进行升级。探针这种东西,虽然看起来是“个人畜无害”的小工具,但总体来说安全风险还是不小,万一被攻破,那探针所连接的服务器毫无疑问都会被“一锅端”。为此,老T在升级探针之余,也对这个探针增加了一点小防护。

相比V0版的哪吒探针,当时服务器之间所用的通信域名实际上是处于“裸奔”状态,无法使用 CDN 进行源站防护,只能尽可能错开域名使用,而V1版探针默认可以支持 Cloudflare CDN,较大提升了安全性。
在账号防护方面,V0版的探针,默认可以启用 Github 账号授权登录,相比较纯账号登录,显然多了一重保障。但V1版探针,默认只有账号登录方式,相对来说后台更容易被攻击。
虽然后来 V1 版也添加了 Oauth2 绑定功能,但启用也麻烦,我在论坛上看了很多人的探针页面,发现启用率不高。并且 Oauth2 实际只是一种补充登录方式,并不能限制仅用这种方式登录。

老T此前已经对自己常用的 VPS 管理面板、NAS 管理面板(外网访问)都添加了访问控制。主要就是使用 Cloudflare Zero Trust 功能,添加 Access 访问控制策略,确保仅限自己访问。


但哪吒面板稍有区别,因为面板前端并不需要设置“仅限自己可见”,只用对探针的后台页面限制访问即可。
使用方法也比较简单。
登录Cloudflare Zero Trust仪表板。
添加或编辑自托管应用:
nezha.sample.com/dashboard/*。配置Access策略:
此前我在另一篇文章提到 Access 策略设置,这里就不重复了: 如何添加-access-访问控制

2025-10-28 23:35:00

最近老T翻旧文章,回忆起当年折腾QQ登录的日子,感慨万千。电话这东西,全球随便打,移动的号拨给联通,秒接通,毫无障碍。可聊天软件呢?微信、抖音、钉钉、微博、QQ等,个个都是 “围墙花园”,互相不搭理。那凭啥电话行,聊天软件就不行?
电话系统能全球互通,表面上看是因为 标准化协议,比如国际电信联盟(ITU)定下的各种规矩,能够在技术上无缝衔接。但老T觉得,这背后应该还有更深层次的原因。
首先,电信运营商,尤其是国内几大运营商,基本都是 国企,比如中国移动、中国联通、中国电信。这些 “国家队”背负社会责任,不是单纯的商业公司。电话作为 基础设施,关系国计民生,必然要求互联互通。老T查了下电话历史,发现早年电话网络刚建时,也有运营商各自为战的情况,比如美国 AT&T 公司就曾禁止过其他电话公司接入其长途网络,但到后来发现 电话不互通,社会成本太高,用户怨声载道,监管层一出手,也就解决了。加上电信行业高度垄断,玩家少,协调起来相对容易,协议一签,网络一连,全球电话网就织成。
再者,电话是典型的 基础设施服务,类似水电煤,服务本质是“连接”,不以内容为核心竞争力。运营商赚的是通话费、流量费,客观上也没什么动力在内容上搞封闭。反过来,互联互通还能扩大用户群,增加收入。所以,技术标准+社会责任+垄断协调+基础设施属性,共同造就了电话的畅通。
老T想起当年2000年左右,家里刚装电话那会,在偏远农村用座机就可以打电话给远方的亲友,移动联通随便拨,完全没想过背后有多复杂。这就是基础设施的魅力:你感觉不到它的存在,但它就是好用。
反观网络聊天软件,情况完全不同。微信、抖音、钉钉、微博、QQ等,个个都像独立王国,互不往来。表面上是 技术问题,协议不统一,加密方式各异,强行互通可能出安全漏洞。但老T觉得,根源还是 商业利益和生态封闭。
聊天软件公司靠 用户数据和生态赚钱。微信有朋友圈、公众号、小程序,抖音背靠字节跳动的广告帝国,微博搞粉丝文化。这些平台的 核心不是“连接”,而是“黏住用户”。开放接口的化,等于把用户往外推,谁干?老T当年写过一篇关于QQ登录的文章,感触颇深。比如Gaim(后来的Pidgin),可以在U盘系统里装过,功能强悍,当年能同时登录QQ、MSN、雅虎通,简直是神器!还有Instango,能同时登上各种聊天软件,还巨省流量。另外还有大量webim工具,像meebo、imtata、imhaha,可以直接在网页上登录多个聊天软件,方便得很。可惜,这些工具都在日后全部歇菜,核心原因就是各家聊天软件纷纷改接口、搞封闭。这些经历也告诉老T,聊天软件的封闭并不是技术难题,而是故意为之。
这几年,各种平台之间在封闭道路上走得更远了。像在抖音上发淘宝、京东链接,轻则限流,重则封号,明明是个很正常的链接,但它动则说这是在“诱导使用第三方平台交易”,属于诈骗。微信这边稍微好点,2021年工信部要求解除外部链接屏蔽后,现在能直接打开淘宝链接了,但分享体验还是别扭,常要复制淘口令。讲白了,还是利益主导,各个网络巨头,护着自家流量池,谁也不想给对方导流。
老T觉得,聊天软件和网络平台现在的状态,跟电信运营商有点像:都有垄断或半垄断属性,也有国资背景(比如腾讯、阿里都有国有资本参与)。但跟运营商不同,聊天软件的核心是内容和生态,数据就是命根子,开放互通等于割肉。所以,技术上能解决,商业上不想解决。
自从老T在一个技术微信群里发出“为什么不同运营商之间可以相互打电话,聊天软件之间却无法相互对话”这个看似可笑的问题后,就知道很难有积极正面的反馈。不过老T对未来依然持乐观态度,觉得互联网继续发展,必然还是要 “以人为中心”!技术上,开放标准协议像 XMPP、Matrix 早就有了,支持去中心化聊天。如果大公司用这些,互通分分钟。监管层也在发力,比如,上边提到工信部要求各家解除外部链接屏蔽等等,国外的话,欧盟的《数字市场法案》也逼着脸书和苹果开放接口。
但这里,老T特别想聊聊 AI 的潜力。AI 在未来互联网互联互通里,可能是一个大杀器般的存在!首先,AI 能当 “协议翻译官”,实现不同平台的内容格式的转换,比如把抖音的消息转成微信能识别的。其次,AI 能优化跨平台体验,预测用户需求,处理加密和隐私问题。更为正面的是,AI 能重塑商业模式。这些大公司完全可以 不靠锁定用户数来赚钱,而是靠提供 AI 服务,比如智能推荐、隐私保护、跨平台协作等等,收入照样来。
老T构想一个场景,假设未来有个 “超级聊天管家” AI 助手,它实时收集你所有平台的信息,比如各种微信的朋友圈更新、QQ的群聊、微博的关注订阅,全汇聚到一个统一界面。你想跟QQ上的老朋友聊天?直接在 AI 里输入消息,它自动转发过去,还处理格式兼容和隐私加密。如果对方用抖音消息,AI 就桥接过去,确保消息准确传递。甚至,你在 AI 里搜索“上周老板发的那个视频”,它能跨平台拉取,秒出结果。这不光省事儿,还能打破围墙,让沟通回归本质:人与人连接,而不是平台绑架。事实上,现在一些手机厂商已经在这方面走的更远了。比如,老T前阵子曾刷到个小米澎湃OS的演示视频:用小米手机内置 AI 语音控制,打开抖音并找到雷军的账号下边某个视频点赞并评论。
当然,老T也只到这种事情挑战不少。商业利益冲突最大,巨头们护数据如命。技术上,协议统一、隐私安全、用户体验都得平衡。监管也得跟上,防止大公司店大欺客。但老T相信,互联互通这种明显的正当需求,在未来应该更加会得到更多的重视,比如微信和QQ就完全可以打通,毕竟都是同一家公司,还分什么你和我呢?
写到这儿,老T不由得回想2000年代的互联网,回望那个 “互联网精神”和“开源精神”的黄金时代!合作、共享、创新,支持着整个人类走入信息化时代。但毫无疑问,如今这种共享、开源精神,遭遇了一定挫折。老T回想起年初看到一篇技术博客,标题叫《人工智能、国家行为者和供应链》,文章提到,全球99%的软件以开源软件为基础,97%的应用程序使用开源代码,90%以上的公司日常依赖开源软件运转。而近年来,整个开源世界,都面临着非常大的挑战,不确定性因素大幅增长,一些网络巨头也借开源之名,行控制之实,互联网从开放走向碎片化,围墙也越建越高。

老T觉得,就像《流浪地球》中表现的那样,人类本应该团结,在人工智能时代,更需要重拾开源精神,构建一个 “互联网命运共同体”。就像电话系统那样,大家放下私利,合作共赢。用户、开发者、公司、政府一起推动标准化和开放,AI 也能帮忙桥接。否则,围墙越厚,用户越累,创新越少。希望未来能回归初心,让互联网真正互联互通。
2025-10-27 08:00:00

最近几年来,老T在静态博客发布这件事情上也算是走了无数弯路。随便搜下老T博客,关于Hugo的数篇文章,无一不是聚焦这个问题。但细数以前的经历,不管是哪种方法,很少有能让老T坚持一个星期以上还主动愿意持续用下去的。大多数时候用它们都是处于一种迫不得已的”窘境“。如今,终极解决方案来了。
国内网络环境下,Github Mobile 是一个远比 GIthub 网站更稳定的应用。老T最开始萌生用 Github issue 当成博客发布端,是在今年初看到 Hackernews 上一则帖子,提到 Github issue 由于几乎无数量、容量限制,可能是最佳的博客写作平台。可由于长期以来 Github 在国内网络环境下一直处于抽风状态,所以老T并没有去试验这种方法。
直到今年 7 月份,老T在为博客添加一个”说说“功能时,才再度想起 Github issue 的便利性,当时也写了个简单教程:只需 2 步简单操作,一劳永逸解决静态博客添加朋友圈、说说之类的功能
不过那一次主要解决的是博客端添加”说说“功能,而发布过程的便捷性方面并没探索,直到最近用上 Github APP + Shortcut Marker ,在手机上只需点2次就能开始添加图片发”说说“,这过程,比微信发朋友圈的4次点击还要简单(打开微信—发现—朋友圈—发布)。
在持续高强度用了几天后,我开始真心喜欢上这种更新博客方式,仿佛又回到从前用 WordPress 的时代。也就是在这过程中,我开始思考,能不能把日常一些短平快的文章,也通过这种方式发布呢?
老T在周五晚上睡觉前,简单构思了一下这个事情。觉得不外乎就是三个问题:1.提取 issue 内容并转换为 markdown文件;2.转存图片;3.触发逻辑设置。于是周末开干,找了个缩小版的老T博客仓库进行测试。最终,只需要添加两个工作流文件即可实现这一目标。

2025-10-27 08:00:00

近年来,静态博客的发布方式层出不穷,但许多方法要么复杂,要么难以长期坚持。本文介绍一种简单高效的方式:通过 GitHub Issue 作为 Hugo 博客的发布端,利用 GitHub Actions 自动将 Issue 转换为 Hugo 内容并部署到 GitHub Pages。这种方法尤其适合喜欢用 GitHub 移动端 App 随时随地发布博客的用户。本教程基于老 T 的实践经验,解决了私有仓库图片下载、标签提取等问题,适合公开和私有仓库。
repo 权限(私有仓库需要)和 workflow 权限(触发工作流)。在 GitHub Settings → Developer settings → Personal access tokens 创建。content/posts/ 目录,用于存放生成的文章。我们需要两个工作流文件:
deploy.yml:将 Issue 转换为 Hugo 内容并提交到仓库。hugo.yml:构建 Hugo 站点并部署到 GitHub Pages。deploy.yml
在 .github/workflows/deploy.yml 中添加以下内容,用于处理 Issue 转换为 Hugo 内容,并触发 Hugo 构建:
|
|
关键点:
github.actor != 'IssueBot' 确保 IssueBot 的提交不会再次触发工作流。repository_dispatch 事件 (trigger-hugo-build) 调用 Hugo 工作流。hugo.yml
在 .github/workflows/hugo.yml 中添加以下内容,用于构建和部署 Hugo 站点:
|
|
关键点:
push 到 master 分支、手动触发,或 repository_dispatch 事件 (trigger-hugo-build)。pages: write 和 id-token: write 用于 GitHub Pages 部署。issue_to_hugo.py
在 .github/workflows/issue_to_hugo.py 中添加以下 Python 脚本,用于将 Issue 转换为 Hugo 内容,支持私有仓库图片下载和标签提取:
|
|
关键点:
download_image 使用 PAT 认证头(Authorization: token {token}),支持私有仓库附件下载。$tag$ 格式标签(支持空格,如 $搞啥 呢$)。YYYYMMDD_X)。创建 PAT:
repo(包括私有仓库访问)和 workflow(触发工作流)。添加到仓库:
h2dcc/lawtee.github.io)→ Settings → Secrets and variables → Actions → Secrets。PAT_TOKEN,粘贴 PAT 值。在 GitHub Issue 中按以下格式编写博客文章:
发布 和分类标签(如 技术、生活)。)。$tag$ 格式添加标签(支持空格,如 $Hugo Post$)。
|
|
deploy.yml 工作流。触发 deploy.yml:
issue_to_hugo.py 运行:
content/posts/YYYYMMDD_X/index.md。master 分支。hugo.yml 通过 repository_dispatch 事件。触发 hugo.yml:
hugo --minify)。检查 Actions 日志:
Sync Issues to Hugo Content 运行:
图片下载成功 和 成功转换 issue #X。master(e.g., Automated: Sync GitHub Issues as content)。Deploy Hugo site to Pages 运行:
Build with Hugo 和 Deploy to GitHub Pages 步骤。检查生成文件:
content/posts/YYYYMMDD_X/:
index.md 包含 frontmatter(title, date, slug, categories, tags, image)和正文。X_uuid.jpg)存在。index.md:
|
|
访问站点:
https://h2dcc.github.io 或私有仓库的 Pages URL)。PAT_TOKEN 有 repo 权限,脚本已添加认证头。repository_dispatch 事件失败。deploy.yml 的 Trigger Hugo build 步骤日志,确认 curl 请求返回 204。$tag$ 格式在最后一行,空格需包含在 $ 内(如 $搞啥 呢$)。YYYYMMDD_X)。content/posts/YYYYMMDD_X/ 后重新运行。deploy.yml 和 issue_to_hugo.py 支持仅处理触发 Issue,减少运行时间。--debug 模式,检查详细日志。通过 GitHub Issue 发布 Hugo 博客,只需几个步骤即可实现从移动端快速发布到自动部署的全流程。相比传统方式,这种方法简单、高效,尤其适合需要随时记录灵感的博主。无论是公开还是私有仓库,配合 PAT 认证和 GitHub Actions,图片、标签、分类都能完美处理。快去试试吧!
2025-10-24 10:35:00

前几天老T在微信群看到有人吐槽:“为啥路由器地址是192.168.1.1这么一串数字,记着费劲,不能弄个简单点的,比如1.2.3.4?” 这问题乍一听挺有意思,老T自己也用过不少路由器,但从来没想过 192.168.1.1 这个数字来源是什么,于是在网上查了查资料,顺便也问了下 AI。不过,在多方查找比对下,发现目前中文互联网上对这个问题的解答,似乎都缺点什么,感觉不是很准确。这里,老T将自己考证的结论总结出来,争取还原出历史的真相。
老T在网上搜了一圈,发现关于“为什么路由器用192.168.1.1”这事,中文互联网上的解释五花八门,AI的回答也大多似是而非。以下是几种常见的说法:
程序员随便选的
不少论坛和文章说,192.168.1.1是程序员“拍脑袋”定的,觉得这串数字“顺眼”或者“简单”。还有人开玩笑说,192.168的二进制(10101000)看着“有规律”,所以被挑中了。老T觉得这说法听起来挺随意,但总觉得没这么简单。
走的人多了就变成了路
老T在知名技术论坛 HN 上发现有一个热门讨论,提到曾参与过多个互联网 DNS 技术标准起草的技术大佬 Stéphane Bortzmeyer 贴出的一封 2009 年的老邮件。该邮件提到,一家公司在一些早期文档中使用了 192.168.x.x 作为示例地址,于是其他人都按照这个来操作,由于用了人多了,后来在制定技术标准规范时,就采用了该方案。颇有“世上本无路,走的人多了也就变成了路”的感觉。由于这个回答权威性很高,也被很多后续文章所采用。

协议规定只能用这个
还有种说法是,192.168.1.1是“协议强制要求”的私有地址,路由器只能用这个范围。AI的回答也常提到 RFC 1918 技术标准,讲到私有地址有三个范围(10.x、172.16-31、192.168),但没解释为啥偏偏是192.168。有人甚至说“1.1.1.1是公网地址,不能用”,但老T觉得这只答了“为啥不用1.2.3.4”,没讲清楚192.168的来源。
历史遗留问题
少数技术博客提到,192.168是1990年代互联网地址分配时“剩下的”,所以被用来做私有地址。但具体咋“剩下”的,语焉不详。AI的回答也常提到 IANA(互联网数字分配机构),但多半是泛泛而谈,细节不够。
老T翻了这些说法后,觉得都不够透彻。网上很多解释要么太笼统,要么带点“想当然”。于是,老T用搜索引擎,指定搜索90年代的英文资料,还查了点IANA的历史记录,试着把这事的来龙去脉掰扯清楚。
简单说,IP 地址就是给网络设备分配的“门牌号”,让它们在网上找到彼此。家用路由器的 192.168.1.1 就是局域网(LAN)的网关地址,手机、电脑通过它连上外网。
老T查了网上讨论最多的 RFC 1918 技术标准《私有互联网的地址分配》,发现互联网早期 IP 地址就担心不够用,在 1996 年圈定了三个“私有地址”范围,专门给内网用,不会跟公网冲突:其中第一个 10.0.0.0 到 10.255.255.255,用于特大型的内网,大概有 1600 多万个地址;第二个 172.16.0.0 到 172.31.255.255 算是中型内网网,大概有 100 多万个地址;第三个 192.168.0.0 到 192.168.255.255,算小型内网,大概有 6.5 万个地址。

家用路由器基本都用 192.168 这段,因为它地址数量足够家庭用,还不跟大公司的内网(10.x.x.x)撞车。
老T又翻了点历史资料,找到的是美国知乎上关于 RFC 1918 的讨论。才发现,原来 192.168 这串数字不是随便挑的,而是 IANA(互联网数字分配机构)在1990年代分配时的一个“随手”选择:
至于为啥是192.168.1.1或0.1,厂商觉得子网第一个地址(.1)当网关最直观,配置简单。Linksys、Netgear这些早期路由器厂商用了192.168.1.1后,其他厂商跟风,慢慢就成了行规。

本来老T也觉得 1.1.1.1 多好记,但也知道,这地址早就有人使用了,毕竟像 1.1.1.1 8.8.8.8 9.9.9.9 101.101.101.101 114.114.114.114 等带有“魔性”的常见好记的 DNS 服务器地址,早就刻进了老T的 DNA,而这些好记的地址,无一不是被互联网大厂或垄断机构所拥有。

现实中,这些好记的 IP 地址所蕴含的经济价值都不可估量,参考域名交易,很多都能卖出几千万甚至上亿美元天价。这种情况下,每家每户自行使用的无法产生任何经济价值的 IP 地址,也就没必要用那么好记的数字了。
另外,由于历史惯性,192.168 已经用了 30 多年,用户和厂商都习惯了。改成别的,哪怕更简单,用户得重新学,厂商得改文档,成本高收益低。比如,早年苹果 Airport 路由器就用 10.0.1.1,但市场反馈不好,后来也改用 192.168.x.x。可见,192.168 这串数字虽不完美,但确实最稳。
虽然 192.168.1.1 不好记,但现在也用不着老盯着这串数字,比如现在多数新买的路由器,会在说明书上注明,可以用miwifi.com 或 router.asus.com 这样的网址连接,直接输网址就能进设置页面,或者很多路由器也都会配有专门的 APP,点几下就能改设置,IP 地址都不用管。
如果想自己换成其他地址,也是挺麻烦的,虽然路由器设置里基本都可以更改网关地址,但其实改了后也很难记住。老T就经常出现改完就忘掉的情况,不得不在每次访问前,先找个设备联网状态去查看,特别是家里有多个光猫、路由器的情况下。

老T折腾一番后,觉得这 192.168.1.1 还真不是程序员故意刁难人。想想 1990 年代确定这个地址的时候是啥条件,可能人家也压根没想到,日后路由器会进入千家万户。毕竟在当年 ADSL 拨号的时代,一个家庭能有一台电脑接入互联网已经很不错了,谁能想到日后每个家庭都会有一大堆需要联网的设备。好在,192.168 倒也不是特别难记,多搞几次,总能记住的。
2025-10-23 17:40:00

前些天老T在知乎简单回答了个关于悬索桥的问题,虽然赞同的不少,但评论中质疑者也很多,主要争论的就是悬索桥主缆损坏是否可维修更换。由于老T本身对桥梁建设一窍不通,只能以最基本的文字阅读能力,通过查找严肃的文献资料,争取将这个事情说清。
这个争论的起因是知乎上一个问题:“怎么看待某大桥在清明假期关闭最右侧车道?” 老T此前写了个简单回答:
桥梁建设又被上一课了。谁能想到悬索桥有一天会面临火灾风险。估计以后主缆高度起码得调到10米以上,否则真是无解。目前这个高度,一辆3米高的大车如果在主缆旁边着火,整个主缆搞不好都得换,需要的时间就说不清了。
虽然是个“抖机灵”回答,但也获得了 300 多个点赞,不过评论区里就争得激烈了。有人说“主缆烧坏了强度降低,有暗伤”,有人直接断言“维修成本约等于修不了”,还有人脑洞大开建议“铺水管加喷淋”或“加气凝胶隔热”,甚至有人阴谋论“车是故意停在那烧的”。
最让老T感到惊讶的是,评论里好几个人都说“主缆没法换,封死在锚碇里了,得先拆梁”,或者“换一根得上亿,换不了就重建”。老T一开始也承认自己不懂这个,后来补充了几个吊索更换的例子,比如江阴大桥换了50多根吊索、润扬大桥两个月换了2根索等。但评论又有人质疑“那些是吊索不是主缆”,没办法,老T确实没意识到还有这种区别,于是又找了英国塞文桥换了主缆中间6米索股的资料补充上,终于算是止住了这波争论。
讲白了,这就是典型的网上“外行看热闹”?桥梁这种专业事,包括老T在内大多数人都不懂,但也都想一吐为快,过程中很容易把事情带偏。于是这次老T决定再继续挖挖一下严肃资料,看看这悬索桥主缆到底怎么回事。
先说说悬索桥主缆长啥样。老T查了交通运输部的桥梁设计规范和一些工程报告,主缆是悬索桥的“脊梁”,由几千根高强度镀锌钢丝平行排列捆绑而成,每根钢丝直径5-7毫米,一根主缆通常有127到271股索股(每股又是一捆钢丝),总直径能到1米左右。外层缠保护丝、涂防腐层,一般设计寿命长达 100 年以上。一般悬索桥就是左右各一根主缆,两端锚固在巨大锚碇里,中间挂吊索吊住桥面。

老T在知网查了十几篇论文,对这个问题主要有三种看法:无法维修更换、维修更换难度极大、可维修更换。
比如,在《大跨悬索桥主缆抗火性能及其防护》这篇文章中,作者多次提到悬索桥主缆无法维修更换,该文章最后结论也是基于主缆无法维修更换,而提出最严格的主缆火灾防护目标:耐火极限 45 分钟、临界温度 300 度。

老T查询的多数论文都显示,由于主缆是悬索桥最核心的组成部分,从设计之初就是伴随桥梁寿命终身的,想要更换维修难度极大、成本极高。

在老T查询的一些较新的论文中,明显出现了与前边不同的声音。具体来说,就是最近这些年,由于新的主缆锚固技术引入,一些新的悬索桥已经可以实现高效更换主缆索股。
例如,在2025年10月23日(刚好是今天)《中外公路》中的一篇《洞庭溪沅水特大桥缆索及锚固系统设计》文章中,作者提到,目前湖南怀化在建的洞庭溪沅水特大桥,其主缆索股采用了防腐性好、更换效率高的多股成品索锚固系统,可以实现对主缆索股的高效更换。

老T进一步查询发现,早在2022年就有一篇东南大学的《超大跨悬索桥重力式锚碇结构及可更换主缆锚固体系研究》,系统分析了原有悬索桥主缆锚固系统的特点,并提出三种新的主缆锚固设计,目标就是实现悬索桥主缆索股的高效更换。

并且,在这篇文章所提出多个新方案之前,作者也对以往悬索桥主缆锚固技术进行总结,指出常见的五类锚固系统中,只有的“预埋钢构件锚固系统、有粘结预应力锚固系统”两种不可更换,而“无粘结灌油式预应力锚固系统、蜂窝式无粘结预应力锚固系统、多股成品索锚固系统”都是可以更换的。只是各种技术下,更换成本和效率有区别。

事情到这里也就告一段落。从老T目前查找的文献来看,悬索桥主缆是否可维修更换,其实已经比较清晰。对于较新的桥梁,很可能会使用新型锚固设计方案,便于更换。而对于较老的桥梁,可能因为当时条件限制,更换起来有极大难度,甚至无法更换。
但这也不意味着老的悬索桥主缆就无法维修。

起码,老T此前在知乎评论中提到的英国赛文桥的案例就比较典型。2016年,英国人对这条已有 50 年寿命的现代悬索桥进行维修,通过打入一个楔子撑开一个工作面,然后将其中一根破损索股切掉了中间 6 米,并重新用螺丝扣接上。整个维修过程,也只是占用了单向 1.5 个车道,并未造成交通中断。
最后,老T觉得,我们外行对桥梁这种专业事,还是应该保持敬畏,但也不要轻易放弃“求知欲”,多翻文献,多找案例,总能拨云见日。懂不懂不丢人,肯查肯对比才靠谱。