小白开发插件，在期间看文件的时候学到的一些东西，特地分享给大家： 博文链接： https://418122.xyz/posts/project/chrome-extension-basic-structure-beginners-guide 插件仓库链接： https://github.com/V-IOLE-T/tab-harbor GitHub 正在尝试上架 Chrome 插件商店 很多人第一次打开一个 Chrome 插件项目时，会看到一堆文件名，然后立刻陷入混乱。 index.html 、 style.css 、 manifest.json 、 background.js 、 content.js 、 app.js 看起来都像"代码文件"，可它们根本不在同一个层面上工作。想真正看懂插件，关键不是背文件名，而是理解这些文件分别处在什么位置，承担什么职责，以及它们如何配合浏览器、网页和用户界面一起运转。 这篇文章想做的事很直接，就是把这些文件背后的逻辑彻底串起来，让你在看到一个插件目录时，能迅速判断每个文件到底在做什么。 index.html 是插件界面的骨架 在 Chrome 插件里， index.html 通常用来描述某个页面的内容和结构。它决定页面上会出现什么元素，比如标题、按钮、输入框、文本区域，也负责把样式文件和脚本文件接进来。你可以把它理解为一个界面的骨架，因为页面里"有什么"这件事，主要就是由 HTML 决定的。 如果一个插件有弹窗界面，那么点击插件图标后看到的内容，通常来自某个 HTML 文件。有些项目把它命名为 popup.html ，有些项目也会叫 index.html 。名字并不重要，重要的是它是否被浏览器当成插件页面真正加载了。 下面这个例子足够说明它的角色： <!DOCTYPE html> <html> <head> <link rel="stylesheet" href="style.css"> </head> <body> <h1>Hello Chrome Extension</h1> <button>点击我</button> </body> </html> 这段代码里，页面里有哪些内容，完全由 HTML 决定。它告诉浏览器，这个页面有一个标题，有一个按钮，同时还引入了样式文件。你在页面里看到的一切界面元素，本质上都从这里开始。 style.css 决定界面看起来是什么样 如果说 HTML 负责把页面元素摆出来，那么 style.css 负责让这些元素有可读性、有层次感，也更像一个真正能用的界面。字体大小、颜色、背景、边距、按钮的外观、元素之间的排列方式，这些都属于 CSS 的领域。 比如下面这段代码： body { width: 250px; font-family: Arial, sans-serif; padding: 10px; } h1 { color: blue; font-size: 18px; } button { background-color: green; color: white; } 这段样式并没有改变页面里"有什么"，但它显著改变了页面"长什么样"。这正是 CSS 的作用。很多初学者一开始会把 HTML 和 CSS 混着理解，实际上它们解决的是两个完全不同的问题。HTML 决定内容和结构，CSS 决定视觉和排版。 放到插件环境里也是一样。无论这个页面是弹窗页、选项页，还是插件扩展出来的其他界面，CSS 的职责都很稳定，就是把原本生硬的结构变成可以阅读、可以操作、也更符合界面习惯的样子。 在插件里，HTML、CSS、JavaScript 分别站在不同位置上 只看 HTML 和 CSS，还只是理解了插件界面的静态部分。一个真正可用的插件，还必须让界面"动起来"，这时候 JavaScript 才会加入进来。 HTML 负责搭出页面结构，CSS 负责赋予它视觉效果，JavaScript 负责让页面对用户的操作做出反应。比如用户点击按钮后获取信息，或者把某个结果显示到页面上，这些都属于 JavaScript 的工作。 下面这段代码很简单，但它能准确展示 JavaScript 的作用： document.getElementById("btn").addEventListener("click", () => { console.log("按钮被点击"); }); 这时候你就能看到三者之间的协作关系。HTML 放了一个按钮，CSS 把这个按钮变得更清晰、易用，JavaScript 让这个按钮具备"点击以后发生事情"的能力。它们共同组成了插件界面这一层的完整逻辑。 manifest.json 是插件的入口和规则中心 当你把眼光从界面移开，就会看到插件最核心的配置文件，也就是 manifest.json 。这个文件的重要性非常高，因为 Chrome 浏览器安装和加载插件时，最先读取的就是它。没有它，插件无法被识别。写错了它，插件也可能根本无法运行。 它承担的职责可以概括为一件事，就是告诉浏览器：这个插件是谁，它有哪些页面，有哪些脚本，想申请哪些权限，以及这些能力应该如何被组织起来。 最简单的内容通常长这样： { "name": "My Extension", "version": "1.0", "manifest_version": 3 } 这里记录了插件的基本身份信息。接着你还会看到它声明插件弹窗页面： { "action": { "default_popup": "popup.html" } } 浏览器读到这里，就知道用户点击插件图标时，应该打开 popup.html 。如果插件带后台脚本，还会出现类似配置： { "background": { "service_worker": "background.js" } } 如果插件需要把脚本注入网页，则可能是这样： { "content_scripts": [ { "matches": ["https://*/*"], "js": ["content.js"], "css": ["content.css"] } ] } 如果插件要访问某些浏览器能力，还得显式申请权限： { "permissions": ["storage", "tabs", "activeTab"] } 所以，从更本质的角度看， manifest.json 的作用，就是定义插件"能做什么、在哪里做、通过谁去做"。这也是为什么它像一个总开关。你后面看到的页面、脚本、权限，最终都要回到这里去确认。 background.js 像插件的后台调度中心 理解了 manifest.json 后，再去看 background.js 就容易多了。这个文件通常不负责展示界面，也不会直接嵌在某个网页里。它更像插件的后台控制层，负责监听浏览器事件、处理全局逻辑、协调不同模块之间的通信。 比如插件刚被安装时，它可以执行初始化逻辑： chrome.runtime.onInstalled.addListener(() => { console.log("插件已安装"); }); 它也可以监听某些全局事件，或者接收来自界面页和内容脚本的消息： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "getData") { sendResponse({ data: "这是后台返回的数据" }); } }); 为什么插件需要这样的文件？因为有些事情不适合写在界面脚本里，也不适合写在网页注入脚本里。比如统一管理状态、协调多个标签页、处理浏览器级别的事件、访问某些只允许后台使用的 API，这些任务都更适合放在后台脚本中。 如果你使用的是 Manifest V3，那么这里还有一个重要变化。 background.js 在很多情况下是以 service_worker 的方式运行的。它不会一直常驻，而是事件来了就唤醒，执行完任务后可能进入休眠。这背后体现的是 Chrome 的设计取向，它希望插件更节省资源，也更容易控制风险。 content.js 是插件进入网页内部后的执行者 如果说后台脚本站在浏览器层面处理逻辑，那么 content.js 站在网页现场工作。它会被注入某个网页中，因此可以直接访问这个网页的 DOM，也就是页面上的标题、按钮、正文、输入框这些真实存在的元素结构。 举个最简单的例子： const title = document.querySelector("h1"); console.log(title.innerText); 这段代码能直接读取网页上的标题内容。它也可以修改页面： document.body.style.backgroundColor = "lightyellow"; 甚至还能监听页面中的某些操作。也就是说， content.js 的核心价值，在于让插件真正进入网页环境，看到页面内容，并对页面进行读取或修改。 不过这里有一个非常容易被忽略的边界。 content.js 虽然运行在网页里，但它依然属于插件。它拥有插件赋予的能力，也受到插件环境的限制。它和页面原生脚本之间并不是完全共享一切的关系，因为浏览器会通过隔离机制防止它们互相污染。这个细节很关键，因为很多初学者会误以为内容脚本和网页自身的 JavaScript 完全是一回事，实际情况并没有这么简单。 插件的核心难点，在于多个运行环境同时存在 当你把 popup.js 、 background.js 、 content.js 放在一起看时，很容易觉得它们全都是 JavaScript，所以好像只是写法不同。真正的区别并不在语法，而在运行环境。 界面脚本运行在插件自己的页面里，只有当这个页面被打开时它才活跃。后台脚本运行在插件后台，专门处理全局事件和中转逻辑。内容脚本运行在目标网页中，负责接触页面本身。这三种脚本虽然都写成 .js 文件，但它们能访问的对象、拥有的权限、存在的生命周期都不一样。 这正是 Chrome 插件学习曲线真正陡峭的地方。你卡住的往往不是 API，而是脑中没有建立"多环境协作"的图景。一旦建立起这个图景，再看文件结构就会清晰很多。 一个最常见的协作流程，到底是怎样跑起来的 假设我们做一个非常简单的插件。用户点击插件图标，弹出一个小窗口，窗口里有一个按钮，点击按钮后读取当前网页标题并显示出来。这个功能很小，但它足以把前面提到的所有角色串到一起。 首先浏览器会读取 manifest.json ： { "manifest_version": 3, "name": "Title Reader", "version": "1.0", "action": { "default_popup": "popup.html" }, "permissions": ["activeTab"], "background": { "service_worker": "background.js" } } 这一步完成后，浏览器已经知道这个插件长什么样，有什么弹窗页面，有什么后台脚本，以及它申请了当前标签页权限。 当用户点击插件图标时，浏览器会根据 default_popup 打开 popup.html 。页面一打开，HTML 会把结构渲染出来，CSS 负责样式，页面脚本负责交互逻辑。如果 popup.html 里有一个按钮和一个显示结果的区域，那么脚本就可以写成这样： document.getElementById("btn").addEventListener("click", async () => { const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); document.getElementById("result").textContent = tab.title; }); 如果需求只是读取当前标签页的标题，这样就够了。但如果你想读取网页内部更细的内容，比如某段正文、某个按钮文本、某个元素属性，那仅靠弹窗脚本通常不够，你就得让 content.js 进入网页现场去执行。 它可以先读取网页内容，然后把结果通过消息机制发回插件系统： const pageTitle = document.title; chrome.runtime.sendMessage({ type: "pageTitle", data: pageTitle }); 这时候如果流程稍微复杂一些，后台脚本就会出场，承担协调者角色。比如弹窗先给后台发消息，后台再联系当前标签页里的内容脚本，内容脚本拿到网页数据后返回给后台，后台再把结果转给弹窗。这个链路看起来绕了一层，但你会发现它的分工很清晰。界面只处理用户交互，后台处理协调和调度，内容脚本只关注网页现场。 示例代码大致可以写成这样。 popup.js ： chrome.runtime.sendMessage({ type: "getPageInfo" }, (response) => { document.getElementById("result").textContent = response.data; }); background.js ： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "getPageInfo") { chrome.tabs.query({ active: true, currentWindow: true }, (tabs) => { chrome.tabs.sendMessage(tabs[0].id, { type: "readTitle" }, (response) => { sendResponse({ data: response.title }); }); }); return true; } }); content.js ： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "readTitle") { sendResponse({ title: document.title }); } }); 把这段流程真正看懂后，你对插件的整体架构就已经入门了。因为你会意识到，插件开发的本质不是单纯地写一个页面，而是把浏览器环境、插件界面和网页环境连接成一个系统。 app.js 到底是什么，它为什么总让人困惑 很多人学到这里，又会看到一个新的文件名，叫 app.js ，然后开始怀疑自己是不是漏学了某种"官方角色"。其实这里最需要澄清的一点是， app.js 并不是 Chrome 插件规范里规定必须存在的文件。它通常只是开发者自己起的名字。 这意味着，当你在一个插件项目里看到 app.js 时，不能直接根据名字判断它一定负责什么。判断它职责的关键，始终只有两件事，就是它在哪里被加载，以及它运行在什么环境中。 如果 popup.html 里有这样的代码： <script src="app.js"></script> 那这个 app.js 很可能就是弹窗页面的主逻辑脚本。它可能负责监听按钮点击、获取输入框内容、调用浏览器 API、更新页面文本等交互行为。比如： document.getElementById("btn").addEventListener("click", async () => { const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); document.getElementById("result").textContent = tab.title; }); 如果它被 options.html 引入，它就可能是设置页脚本。如果它出现在 manifest.json 的后台配置中： { "background": { "service_worker": "app.js" } } 那它虽然名字叫 app.js ，实际承担的就是后台脚本的职责。如果它被声明在 content_scripts 中： { "content_scripts": [ { "matches": ["<all_urls>"], "js": ["app.js"] } ] } 那它本质上就是内容脚本。 所以，理解 app.js 最重要的一句话是， 文件名本身不决定身份，加载位置和运行环境才决定身份 。很多初学者容易被文件名带偏，以为名字像什么就是什么。实际开发里， main.js 、 index.js 、 app.js 这类名字都很常见，它们更多反映的是工程命名习惯，而不是浏览器规范。 判断一个脚本作用时，最可靠的方法是什么 如果你以后再打开一个陌生的插件项目，最稳妥的阅读方式就是先看 manifest.json ，再看 HTML 文件，最后才去看具体脚本内容。 manifest.json 会告诉你有哪些页面、有哪些后台脚本、有哪些内容脚本、申请了哪些权限。HTML 文件会告诉你哪些 JavaScript 是页面脚本，因为它们会被 <script src="..."> 直接引入。脚本内容本身才会进一步告诉你，这个文件内部具体写了什么业务逻辑。 这个阅读顺序很重要，因为它会强迫你从"运行上下文"去理解代码，而不是从"文件名猜测"去理解代码。你一旦形成这种习惯，不光看 Chrome 插件会快很多，将来学 Vue、React，甚至看更复杂的前端工程，也会有更强的拆解能力。 学插件时，最推荐的理解路径 对于初学者来说，最容易迷失的地方，是一上来就想把所有文件和 API 全部记住。这样做通常效果很差，因为你的脑海里没有一张系统图，记忆就没有挂钩点。 更好的路径，是先看清谁负责界面，也就是 HTML、CSS 和页面脚本。然后理解谁负责进入网页读取和修改内容，也就是 content.js 。最后再理解谁负责监听全局事件、连接各个模块、处理中间调度，也就是 background.js 。当这条主线建立起来以后，消息传递、权限管理、脚本注入这些内容都会顺势变得可理解。 如果你一定要用一句话概括整个插件结构，那么这句话可以写成这样： manifest.json 先注册角色并声明权限，HTML 和 CSS 负责界面呈现，JavaScript 负责交互逻辑， background.js 负责后台调度， content.js 负责进入网页执行具体动作，而 app.js 是否重要，取决于它究竟被谁加载、运行在哪个环境里。 结尾：真正该建立的，是"环境意识" 学 Chrome 插件，表面上像是在学很多零散文件。更深一层看，你其实是在学习多个受控运行环境如何协作。浏览器层、插件界面层、网页内容层，这三层有各自的边界，也通过消息和配置互相连接。你一旦抓住这个系统视角，就不会再被文件名和目录结构轻易迷惑。 所以当你下次看到一个插件项目时，先别急着问"这个文件名是什么意思"。更值得问的是，这个文件由谁加载，它运行在哪里，它能访问什么，它和谁通信。只要这四个问题想清楚，整个项目的骨架就会慢慢显形。 【拓展思考】 Chrome 插件很像一个小型多进程系统。弹窗脚本、后台脚本、内容脚本分别处在不同上下文中，消息传递像协议，权限声明像访问控制，页面注入像受限部署。你如果从系统设计的视角理解插件，后面学浏览器扩展、Electron、前端工程化，很多概念都会互相打通。 2 个帖子 - 2 位参与者 阅读完整话题
哪个有的佬，可以分享一下这个终身许可密钥吗，之前有，结果电脑的系统盘坏了重装系统过后就找不到了。 如有佬可以分享，感谢感谢 1 个帖子 - 1 位参与者 阅读完整话题
庆祝在L站发的第二个项目突破github100 star 「开源」Antigravity(反重力) 上下文监控插件v1.15.0–全方位重构更新，从"上下文监控"到"全维度 AI 监控仪表盘 - 搞七捻三 - LINUX DO 过年期间 在站内发出的该项目宣传， 陆陆续续的到现在终于达成了100 stars ， 收获了近1.7w的下载量 特此庆祝下 顺便再向各位佬友安利一下在站内新发的,欢迎各位来使用 「开源」Memory Palace 版 一 致力于打造更适合openclaw的记忆系统，让你的小虾更懂你，帮助你科学养虾（已更新极简版介绍，路过的佬友看开头即可） 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 TL;DR… 帮助各位科学养虾 ，让你的小虾更懂你 特此庆祝， 10个6.66元的口令红包 。 「抽奖」6.66元口令红包 * 10 奖品详情： [奖品1]：6.66元口令红包 * 10 活动时间： 开始时间：2026年4月18日 18:50 截止时间：2026年4月20日 18:50 参与方式： 回复：祝L站越办越好，大家一起进步，相关内容即可 抽奖规则： 每位用户仅允许参与一次 。 使用 https://lottery.linux.do/ 官方抽奖工具 随机抽取中奖者。 注意事项： 本活动将在活动截止时间后关闭回帖，以确保公正性。 中奖者将在活动结束后24小时内在本帖公布，并 通过私信通知你口令红包，请及时领取 。 请在 收到口令红包私信后及时领取，逾期视为自动放弃 。 口令红包将通过私信发送，请确保能接收私信。 所有规则及抽奖结果由活动发起人和论坛管理团队最终解释。 83 个帖子 - 83 位参与者 阅读完整话题
无论是在vscode的插件中使用，还是各种版本的gui中，都有一个通病 那就是: 可能ai还在回复，还在执行，因为时间比较长，或者是网络有延迟，或者是输出的信息让gui工具以为这就是最终的回复结果了，然后就戛然而止 即使他说接下来执行什么什么，但是界面中就是已经停止了， 看图： 这个是我使用的是vscode中的插件，昨天感觉很顺滑，今天更新了一下，然后又开始了 其他的gui工具有同样的通病，还是老老实实回到cli吧 1 个帖子 - 1 位参与者 阅读完整话题
已经在cc-switch中勾选了应用到vscode中，cc插件更新到最新版本，不选opus 1m会提示1m 上下文已经全量可用，选了1m，报错如下，终端的话是正常使用的： 1 个帖子 - 1 位参与者 阅读完整话题
Codex Computer Use 插件非美国地区并没有正式开放 表现为 更新之后 打开 Codex 的设置页面–电脑使用–Computer Use 插件不可用。 Codex for Mac 安装包里其实已经带了 computer-use 插件，只是非美国地区默认不在设置页开放 先确认插件本体确实在应用包里 /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use 把 Codex 自带的 bundled plugins 注册成一个 marketplace codex marketplace add /Applications/Codex.app/Contents/Resources/plugins/openai-bundled 检查 ~/.codex/config.toml，确保有这段 [plugins.“computer-use@openai-bundled”] enabled = true 打开 remote_control 功能开关 codex features enable remote_control 完全退出并重启 Codex for Mac 重启后去设置页的 Computer use，理论上就能看到插件并安装。 首次使用时给 macOS 权限 主要是： 屏幕录制 辅助功能 / 控制电脑权限 如果你觉得太麻烦 发给 Codex 让他自己弄 1 个帖子 - 1 位参与者 阅读完整话题
虽然目前有一个 zenobi-us/pi-dcp ，但是已经两个月没更新了。 之前用opencode的时候感觉 Opencode-DCP/opencode-dynamic-context-pruning 很好用，可以不声不响地把context 保持在一个很低的水平。 换到pi-agent后，context动不动就飙升到40-50%。试了一下 mksglu/context-mode 和 MasuRii/pi-rtk-optimizer ，效果都不明显。用pi-agent的佬们，有没有什么好的管理办法？ 1 个帖子 - 1 位参与者 阅读完整话题
站内有很多脚本清理401的，但每次都要找到文件然后打开终端运行脚本，感觉有点麻烦。可能适合服务器定时调用，但我是本地开发不太想在本机弄定时任务。就根据站内的方法改写了个油猴插件，安装之后在该页面会出现账号统计，以及清理工具。 一直在纠结是否要加禁用的功能，因为很多脚本都有禁用额度耗尽的，而且禁用了之后没有恢复开启，额度刷新也不会开启，手动开启也很慢。现在的号不如之前容易弄，能等到额度刷新也不想把号废了，而且现在古法插件注册的号存活率还蛮高的。 关于账号耗尽账号是否要禁用可以查看该issue，cpa内置已经考虑了额度耗尽调过移除队列和恢复之后重回队列的逻辑。因此禁用额度耗尽的账号属于负优化，所以我增加了一个一键启用的功能，帮大家把被禁用的账号全部启用。 github.com/router-for-me/CLIProxyAPI codex认证文件，在额度用完是否需要关闭？ 已打开 01:36AM - 08 Apr 26 UTC 已关闭 05:41PM - 12 Apr 26 UTC aicloud-cpu 开源作者们，你们好！ codex认证文件，在额度用完是否需要关闭？ 如果不关闭，轮询会不会跳过这个额度已经用完的认证文件？ 如果关闭了，系统自动刷新toke … n的时候会不会跳过不刷新？ 脚本内容太长没办法直接贴进来，大家自行下载吧。 clear_401.user.js.7z (16.6 KB) 2 个帖子 - 2 位参与者 阅读完整话题
最近使用了一个双持插件EditorJumper，使用后感觉挺方便的，分享一下 插件的主要作用是在同一个文件中保持的光标位置和编辑上下文位置，按快捷键（win:Alt+Shift+O / mac:Option+Shift+P）在vscode系列和jetbrains系列编辑器间进行跳转。 我的使用场景是在 TraeCN/CodeBuddyCN 中进行 vibe Coding, 在 IDEA 中进行编辑和Git提交 个人习惯以及喜好吧， vscode系的编辑器中写代码总感觉有些别扭， GIT插件也怪怪的 jetbrains系列安装这个 （点击了解更多详细信息） vscode系列安装这个 （点击了解更多详细信息） 1 个帖子 - 1 位参与者 阅读完整话题
， 佬们，我现在写的程序是单片机程序使用编码是gb2312编码，我用的是vscode的插件codex，但是这个gb2312编码老是乱码，每次ai总是检测到乱码然后再把乱码改好，怎样优雅的使用2312编码不乱码啊！！！ 1 个帖子 - 1 位参与者 阅读完整话题
昨天我使用codex login登录了官方账号之后，codex插件突然少了很多功能。具体表现为 文字全部变成了英文 “/” 命令不会弹出任何提示，之前输入“/”会出现skills、mcp、status等内容 尝试过卸载重装插件、切换别的供应商，均无法解决。 2 个帖子 - 2 位参与者 阅读完整话题
如果你经常在终端里使用编程助手（比如 cc、cx），有时 会不确定模型是不是卡住了 偶然发现了个项目，—— 这个项目可以帮你解决这个问题，【 CodeIsland — Your AI agents live in the notch 】 之前用 但是不支持 cx 觉得好用的佬友，帮帖子点个赞吧 感谢 2 个帖子 - 2 位参与者 阅读完整话题
为啥claude会话老是这样中断呢？ 4 个帖子 - 2 位参与者 阅读完整话题
在github闲逛，发现一个claude code的自动提取内存的插件，叫claude-mem，大概就是自动根据几个hook，提取内容保存，自动增加内容提问，大概就是这个意思，不过一看provider，只支持御三家，无法填国内的，看着挺好的，就是用不了，实在没国内版本的我就打算后面自己写一个算了，有的话还请佬推荐一下。 顺便说一下这个东西的作用，最近hermes之所以这么火，也是因为他的自学习能力，所谓自学习能力，其实就是内存管理，跟上面的原理是差不多的。所以claude code有了这个，等于变相也成了一个可以自己学习的编程智能体。 4 个帖子 - 3 位参与者 阅读完整话题
copilot额度被opus小姐蹬完了，不想几个IDE切来切去的，有什么自定义copilot接入点的插件吗 站内搜了下都是比较老的copilot版本，还有失效的方法 不行的话，只能看看能不能反向代理里面的地址做转发了 10 个帖子 - 5 位参与者 阅读完整话题
vscode远程连接服务器、服务器网络是走本地代理。使用codex插件时没有网络、可以正常使用cli。奇怪的是我有三台服务器、有一台可以正常使用插件。怀疑是缓存问题但是一直没解决。有佬友知到解决办法吗 1 个帖子 - 1 位参与者 阅读完整话题
佬友们大家好，我准备买个友善R3s当主路由，只跑一个nikki代理插件，1g内存版本够用吗 9 个帖子 - 9 位参与者 阅读完整话题
最近看美剧想不看中文只看英文，不想养成习惯，但是找不到能用的遮挡字幕的工具，佬们有推荐吗 4 个帖子 - 3 位参与者 阅读完整话题
如图，目前Windows终端和vs的默认已经换了powershell 7了，聊天已经正常了，就这个标题还是这样，虽然不影响使用，但是看的难受 1 个帖子 - 1 位参与者 阅读完整话题
原项目地址： QLHazyCoder/codex-oauth-automation-extension: Chrome扩展：支持OpenAI OAuth注册、验证码获取、CPA回调验证与自动恢复 dreamhunter2333/cloudflare_temp_email: CloudFlare free temp domain email 免费收发 临时域名邮箱 支持附件 IMAP SMTP TelegramBot 基于codex-oauth-automation-extension V10.0.0和cloudflare_temp_email V1.6.0 由于需要接入cloudflare_temp_email V1.6项目，和接入HeroSMS，用gpt5.4搓了一个注册机。 脚本默认使用泰国的号码进行注册，如果需要其他国家的号码，可以自行修改插件。 一个号码可以验证3个gpt帐号，如果验证提示手机号超过验证上限会自动重新申请号码。 HeroSMS的服务代码：OPENAI为’dr’ 泰国(+66)的国家代码为’52’，更多信息可以查询网站： 服务代码: https://hero-sms.com/stubs/handler_api.php?action=getServicesList 国家代码: hero-sms.com/stubs/handler_api.php?action=getCountries HeroSMS接码大概0.05$一个号码也就是3到4毛一个号码，可以验证3个帐号，大概1毛多一个号。 注册一个号大概2分到3分钟，总结偶尔会有一些问题，例如接码的问题，需要手动终止和排查一下。适合自己使用的CPA，不适合大型公益站。 为了各自财产安全，不要随意分享自己导出的json配置文件，里面包含了CPA密码，HeroSMS-API和cloudflare_temp_email管理员邮箱密码 可以偶尔查看自己的HeroSMS的余额以及号码，脚本偶尔会有没有接码成功的情况。 原作者帖子： (注意：再次复活，赶快注册)自动化古法注册（4月17号凌晨5点 v11.0.0版本发布）【一键CPA/SUB2api认证+gpt注册+上传】Chrome插件（七天不到star数已经破1.7K啦） - 开发调优 / 开发调优, Lv1 - LINUX DO 喜欢可以点点赞 2 个帖子 - 2 位参与者 阅读完整话题