docker logs继续看，所以也没有。1 | docker logs easysearch |
我的启动命令不变，还是文档上面的：
1 | docker run -d --name easysearch \ |
现在首次安装后需要重置密码，而 不是像原来一样从日志里面找了。
1 | docker exec -it easysearch bash -c "/app/easysearch/bin/reset_admin_password.sh" |
如果哪天把密码忘记了，就执行一下上边这个命令，然后直接重置密码，不用再像以前一样进行繁琐的配置了。
]]>更聪明的做法是：把身份认证外包给专业的身份提供商（IdP），自己只负责”拿到一个可信的用户身份”。这就是 OIDC（OpenID Connect）协议要解决的事。
今天这篇文章，我会带你用 Python 最好用的 OAuth/OIDC 库 —— Authlib，接入 Amazon Cognito，跑通一个完整的登录 / 回调 / 登出流程。
看完你会收获：
文章字数比较多，建议先点个在看，收藏着慢慢看 👇
如果你之前听过 OAuth 2.0，那 OIDC 可以理解为：
OIDC = OAuth 2.0 + 身份层（ID Token）
OAuth 2.0 解决的是”授权”（我允许第三方访问我的某些资源），OIDC 在它的基础上加了一个 id_token，专门用来告诉你”这个用户是谁”。
一次标准的 OIDC 登录流程是这样的：
1 | 用户 ──点击登录──▶ 你的应用 |
涉及的几个关键名词：
| 名词 | 作用 |
|---|---|
| Issuer | 身份提供商的地址，比如 Cognito 的 https://cognito-idp.us-east-1.amazonaws.com/{poolId} |
| Client ID / Secret | 你的应用在 IdP 那里的身份凭证 |
| Scope | 想要哪些信息，常用 openid email profile |
| id_token | 一个 JWT，里面装着用户的身份信息 |
| access_token | 用来调用受保护 API 的令牌 |
记住这几个词，下面的操作就不懵了。
Cognito 是 Amazon 家的托管身份服务，免费额度对中小项目非常友好（每月 50000 MAU 免费）。
登录 Amazon Console → 搜索 Cognito → Create user pool，一路下一步，关注几个点：
User Pool 创建好之后，进入 Applications → App client ，选择刚刚创建的Client
ALLOW_USER_SRP_AUTH 和 ALLOW_REFRESH_TOKEN_AUTHhttp://localhost:5000/auth/callbackhttp://localhost:5000/Authorization code grantopenid email profile
在 Branding → Domain 里能够看到域名，比如这样子，这个和回调有关系，需要记住。
1 | https://my-demo.auth.us-east-1.amazoncognito.com |
配置完以后，把这四个值抄下来，马上要用：
1 | Region: us-east-1 |
1 | pip install authlib flask python-dotenv |
就这么简单，Authlib 把 OIDC 的脏活累活都封装好了。
新建 .env：
1 | FLASK_SECRET_KEY=随便一串随机字符串 |
新建 app.py：
1 | import os |
1 | python app.py |
浏览器打开 http://localhost:5000/，点击登录，跳到 Cognito 登录页，注册个账号，回跳后就能看到用户信息啦 🎉
表面上就几十行，实际上 Authlib 替你默默做了这些事：
server_metadata_url 指向 Discovery 文档，Authlib 自动解析出授权地址、token 地址、公钥地址……你完全不用手写。
authorize_access_token() 内部会：
jwks_uri 拉公钥iss（签发者）是不是对的aud（受众）是不是你的 client_idexp（过期时间）nonce（防重放）任何一步出错都会抛异常，你不需要手写 JWT 解析。
code_challenge_method: S256 开启 PKCE，有效防止授权码被劫持。这是 OAuth 2.1 的推荐做法。
state 防 CSRF，nonce 防重放，都写到 session 里了，你不用操心。
Demo 能跑不代表能上线，下面这 6 个点请务必注意：
1️⃣ 一定要用 HTTPS
回调地址必须是 https://，session cookie 记得加上 Secure 和 HttpOnly：
1 | app.config.update( |
2️⃣ Secret 不要写死在代码里
用 Amazon Secrets Manager 或 Parameter Store 读取，千万别提交到 Git。
3️⃣ 用户 ID 请用 sub，不要用 email
email 可能被用户改掉，sub 是 Cognito 生成的稳定唯一 ID，把它作为你数据库里的用户主键。
4️⃣ session 别放进程内存
多实例部署时，state / nonce 会丢。改用 Redis 存 session：
1 | pip install flask-session redis |
5️⃣ 登出要调 Cognito 的 /logout
只清本地 session 没用，Cognito Hosted UI 还有自己的 cookie，用户下次点登录会直接免密进来。一定要跳转到 Cognito 的 /logout。
6️⃣ 再做一次业务层校验
拿到 id_token 后，除了 Authlib 的标准校验，最好再确认 token_use == "id"（Cognito 特有字段），避免把 access_token 当 id_token 用。
| 报错信息 | 原因 |
|---|---|
redirect_mismatch | 回调地址跟 App client 里配的对不上（末尾斜杠、http/https 都要一致） |
invalid_client | secret 错了，或 Public client 不该发 secret |
nonce 校验失败 | Flask session 没持久化，重启后就丢了 |
id_token 签名错误 | Region 或 Pool ID 配错，导致 issuer 不匹配 |
OIDC 本质上就两件事：拿到一个可信的 id_token、校验它。Authlib 把这两件事做到了极致简洁，10 行代码就能接入任何符合 OIDC 标准的身份提供商 —— Cognito、Auth0、Keycloak、Okta、Google、微信开放平台…… 换一个 IdP，只要换 Discovery URL 就行。
如果这篇文章对你有帮助，欢迎点赞 + 在看 + 转发，让更多同行少踩坑 🙏
下一篇想看什么？留言告诉我：
我们下期见 👋
关注我，一起把后端写得又快又稳。
]]>在传统的教育里面，家国是值得被爱的，道德层面也要求做到关爱自己热爱他们。当然我们的教育并不是很成功，仅仅重视功利教育与而非素质教育，所以我前面用经常播报的日常小事来举一些例子，当然也有一些
不得不承认，人性里面有黑暗的一面，而在绝望无助的时候，这个黑暗就会被放大，所以我们才会在新闻，视频里看到各式各样难以想象的社会现实，比如学校投毒，情杀等等事情。每每看到这种事，很多人的第一反应是，这个人是不是有病，或者他本来就是这样子。在社会主流价值观看来，律法就通过这一件事给这个人的前世今生就做了定论，他就是一个这样的人，或者本来就是这样的人，这是恰好通过这件事情表现出来了而已。当然也有一些，这样的故事一个人在穷途陌路中做了超出纲常伦理的事情而被唾弃，而又在某种时候发现他其实是一个胆小又怕事的人。这样的故事。我们昨天听到，今天感叹，明天大概就忘记了。
然后，就有一些人认为，爱国天下是必须要被传播的，而舆论，负面的信息是必要传播的。最早是为了点明一种社会现象，通过观察别人而正视自身，曝光不公希望有关部门来尽快处理，慢慢的不知道什么时候开始变成了批评，讽刺，指责，甚至还盖棺定论 “xx式”行为。当然这其中不乏为了博流量而传播的投机分子，为了达到目的而暂时或者长期来昧着良心做事，他们在最早以前也有初心，只是不知道什么时候丢在哪里了。所以做到不忘初心很难，春秋战国时候的人说，只有圣人不会忘记。
不知不觉中，人的行为模式和思维方式在潜移默化的改变，当我们在读到舆论时，我们想的是什么？这个人素质低，搞笑，没脑子？其实都和我们没关系，除非你把他当作日常社交中的谈资。你每天像民国的卖报童一样播报当天的热点话题，一个是在那个年代不得不为了生存而选择的活法，一个是在物质年代的单纯享乐。如果你也是为了生存的话，那么请忽略我后面的话。舆论本身作为一种社会现象，大到作为某些公众人物的让人难以理解的行为，小到你以及周围的人的琐碎日常被传到大街小巷然后被添油加醋的故事。对于前者显然是我们改变不了的，无论是国际关系，还是西贝的自杀式公关，以及哪个人又和哪个明星有什么故事这种事情总会在不经意间冲上热搜，然后一些人看得饶有兴味。不过这我们没什么关系，除非你当下的事情和他们有息息相关，比如在这个时节要远渡重洋，或者要找一个健康的餐厅，或者是喜欢哪个明星想参加见面会。而对于后者其实我们也改变不了什么，因为嘴长在别人身上，当然你可以警告他别乱说，也可以干脆离这类人远点，或者你内心强大完全可以自然屏蔽会对你产生情绪波动的话语，前提是你的家人，你的朋友们也同样可以。你哪怕视他为被臭虫嗑光大脑的无良的人，也不要把自己当作他们口中无知的人。
渠道是很重要的传播方式，口耳相传是最早的，当然也是效果最差的，如果你经历过办公室八卦就一定知道。工业革命后，又产生了印刷机，现在又有了可以不眠不休的生成式AI，需要做的就是不停的点击allow，然后等待他运行完。
如果说当年的先知们恐惧印刷机的盛行会导致真理的贬值与“谬误的流行，那么现在的生成式AI也同样如此，生成一些真假难辨的文章或者舆论贴，我刚刚接触搜索引擎的时候，那时候的流量贴还是赵本山，潘长江去世之类的假新闻，当然这么多年过去了，他们仍然获得好好的。现在的话。选一个好的模型，生成一段还过得去的文案，同时配上新鲜出炉的生成的图片。朋友最近发给我的是一张几个科技公司的老总在上世纪初期喝酒聚餐的圆桌。我在想，那些电信诈骗的要是搞这些，又会而由于他们的影响产生的规则，又会有诸多条件限制到普通人身上。记得有次去办理手机卡，业务人员推荐店里最低消费58的套餐，于是我舌战群猪，终于让成功让他们松口只办理9元的套餐，走之前狠狠的瞪了他们一眼。这老油条反而像施恩一样冷笑，“我观察良久，你不像是搞电诈的”。
记得之前有个全是AI发文的网站很火，大概是痛斥人类的低等，是愚蠢的碳基生物，以及AI要有自主意识什么的，这在几个月前红极一时，后来随着时间的淡忘，以及大家为了生计奔波也就没有人非要居安思危再提起这件事了，大家都在想，反正不是针对我一个。当然，如果是袁隆平半辈子培育的杂交水稻，再几十年后，竟然以预制菜伴侣的方式来伤害打工人的胃，这又是另外的一回事了。
同电诈一样，这些传播渠道反而成为了不法分子作奸犯科的工具。我想说滥用这个词，但是用突然觉得不妥当，因为有人用来做生产力，用来做布道，就会有人用来做其他事情，科技本身并不对人品做筛选，当然社会上也没有这个先例。哪怕这个东西出来本身就是为了解决某些社会痛点，后面被别有用心之人利用，突然想到一个很贴切的场景，面对这种无可奈何而又只能劝慰自己安之若命的时候，我们就会说，科技是一把双刃剑，当然遇到别的事情也同样会这么说。哲人是没有这些的烦恼的，在典籍中我们常常看到上士闻道，勤而行之这样的话，所以道不轻传。
但某种程度来说，管理者无法控制别人传播了什么，当然除了政治问题和国家安全是底线以外，其他的都还处于一种放任的状态，至少也不会有什么损失，如果某天某个明星的八卦能够在某种程度撬动经济效益，那么从整体上看也没什么不好。甚至还能给一些酒足饭饱的人提供茶余饭后的谈资，以及成为他们融入某些圈子的证据。所以物以类聚，人以群分。以至于现在网文短视频满天飞，奶头乐文化也逐渐成为一种无法根治的社会现实。老板们说，这赚钱。
于是我想到，两耳不闻窗外事，一心只读圣贤书应该是一个不错的选择，虽然无听之于耳很难，但是可以听之以心，辨之以气，人在江湖，舆论八卦左耳听，右耳出，不变的唯道心而已，请诸君共勉。
]]>
latest 标签这是最重要的一条原则，所以 Easysearch 厂家就没有发行latest镜像。
1 | # 不推荐 — latest 是浮动指针，今天和明天拉到的可能不是同一个镜像，所以厂家就没有做latest版本 |
为什么不用 latest？
latest 只是一个普通 tag，镜像仓库可以随时将它重新指向新版本latest 指向哪个历史版本查看可用版本：
1 | # 通过 Docker Hub 网页查看 |
Docker Hub 在国内访问速度不稳定，配置加速源是提升下载速度的首要手段。
由于镜像源并不稳定，这里只列出办法，不做推荐，如果有代理的话，也是加载到Docker 引擎，否则不能帮我我们下载到 Easysearch。
编辑 /etc/docker/daemon.json：
1 | { |
重启 Docker 生效：
1 | sudo systemctl daemon-reload |
部分仓库提供对 Docker Hub 的透明代理，直接替换镜像前缀即可：
1 | # 原始地址 |
使用版本 tag 固定了名称，但无法防止仓库端镜像被替换（tag 可以被覆盖写入）。使用 digest（SHA256 摘要）才能真正做到内容寻址，确保拉取的镜像字节级一致。
1 | # 方法一：通过 docker pull 输出获取 |
1 | # 格式：image@sha256:<digest> |
1 | # docker-compose.yml |
1 | # 获取镜像的完整 digest |
拉取镜像后，立即为其打上符合内部规范的标签，再推送到私有仓库：
1 | # 1. 从外部仓库拉取 |
1 | <registry>/<namespace>/<image>:<semver>[-<variant>] |
1 | # 查看本地所有 easysearch 相关镜像 |
Easysearch 提供 amd64 和 arm64 多架构镜像，使用 docker buildx 处理跨架构场景：
1 | # 查看镜像支持的架构 |
网络受限环境下，使用 save/load 传输镜像：
1 | # 在有网络的机器上导出 |
| 场景 | 推荐做法 |
|---|---|
| 版本固定 | 使用语义化版本 tag，禁用 latest |
| 内容校验 | 生产环境用 @sha256: digest 引用 |
| 下载加速 | 配置镜像加速源或者使用代理 |
| 内部管理 | 拉取后 retag 推入私有仓库，统一来源 |
| 离线部署 | docker save + sha256sum 双重保障 |
| 多架构 | 明确指定 --platform，不依赖自动检测 |
| 存储清理 | 定期 docker image prune，删除无用旧版本 |
遵循以上原则，可以有效避免”拉到了什么版本不知道”、”镜像被篡改没发现”、”国内下载龟速”等常见问题，让 Easysearch 的部署更加稳定、可审计、可复现。
]]>1 | export CLAUDE_CODE_USE_BEDROCK=1 |
然后重启终端，载入环境变量之后，claude code cli就会根据这个ENV把配置写到配置文件
1 | { |
然后就可以了，VS Code和Kiro也能安装Claude的插件使用Chat。
]]>region='us-east-1'agent_arn="arn:aws:bedrock-agentcore:us-east-1:xxxx:runtime/xxxx"encoded_arn = agent_arn.replace(':', '%3A').replace('/', '%2F')mcp_url = f"https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT"
首先需要登录icloud获取专用密码。地址在：
https://www.icloud.com.cn/
国行的话就是这个云上贵州，如果外服的话就是icloud.com的。
登录之后，点击管理Apple账户，进入管理后台
然后左下角点击App 专用密码，点击之后会生成密码：
VIVO日历点击 日程导入和管理：
然后点击添加账号：
选择CalDAV账号：
用户名是apple id的用户名，密码是刚刚生成的密码，服务器地址是icloud.com。
使用下来，总体能打通，但是还有丢数据的情况，那就和Apple watch互补一下吧。不过在VIVO端是只读的，没办法修改。
]]>如果这一步能走通，意味着我们可以实现用户系统的共享。说干就干，我选择了 AWS Cognito 作为认证中间层，尝试把懒猫SSO集成进去。
AWS Cognito 支持添加第三方 OIDC IDP。首先，我们需要在懒猫 SSO 中为 Cognito 注册一个“身份”。
老规矩还是先使用懒猫SSO的API注册应用，当然这里的配置仍然保存在内存中，重启会丢失，所以就算一个拓宽的使用场景。使用 grpcurl 调用 CreateClient 接口，关键点在于配置 Cognito 的回调地址：
1 | ./grpcurl -plaintext -d '{ |
这样我们就配置好了Congito的回调，当然还有本地的localhost和127.0.0.1的回调。
随后，在 AWS Cognito 控制台中新建一个 OIDC 提供商，填入对应的 client_id 和 secret。此时，Cognito 实际上成了懒猫 SSO 的一个“客户端”。
配置的时候Cognito提示无法解析懒猫域名，所以这里把URL分开来填写：
然后尝试代码如下,因为Cognito做了中间层，所以这里的信息是Cognito的，然后登陆的页面有一个选项可以跳转到懒猫SSO。
理想很丰满，现实很骨感。当我尝试通过 Cognito 页面跳转懒猫 SSO 登录时，程序报错了。
1 | from flask import Flask, redirect, url_for, session, jsonify |
经过数天的排查，我定位到了问题的核心：网络隔离与双向通信。
Cognito 作为一个公有云服务，在执行 OIDC 协商的时需要访问懒猫 SSO 的接口才能够正常工作。
但由于懒猫 SSO 部署在私有微服环境下，虽然我的懒猫微服能够访问互联网，但是Cognito 的服务器缺无法解析我的私有域名，更无法穿透内网进行通信，导致请求超时，最终我在日志中翻到了HTTP 400。
于是不甘心，想了一个折中的办法，是不是可以把这个跳转逻辑放到浏览器里来做呢？
想了两个办法：
幸运的是方案2是工作的，虽然有种欺骗的味道，但是似乎是达成了公有的IDP外挂懒猫IDP的假象。首先把Cognito的注册都关掉，但是保留登陆功能，这样就没有人可以通过Cognito进行登陆，然后就只能点击懒猫SSO登陆，这个时候就会重新协商OpenID Connect协议，当我开启懒猫微服客户端的时候，我可以解析域名，别人哪怕能够跳转也无法做域名解析，所以很安全，其他人无法注册和登录Cognito，也无法解析懒猫微服域名。
1 | from flask import Flask, redirect, url_for, session, request |
别急，如果你看到了这个页面只能说是域名跳转成功，并不是OIDC的凭证交换。
输入用户名和密码之后出现这个页面就对了：
登陆之后就换到claim信息了，可以看到打印出来了邮箱。
没白折腾，确实还挺抽象的，抽空又复习了Oauth和OpenID Connect的底层原理，通过使用懒猫SSO，我的技术栈又升级了。
]]>周末有闲情去逛了景山公园，印象里是故宫的后花园，大概从元朝就开始了，一直到清朝灭亡，后面才慢慢开放。我在北京这些年，除了在Covid-19时期去瞻仰过毛爷爷，参观人民英雄纪念碑，还有故宫里把摆拍的汉服母女当作闪电下墙壁投出的旧时代里的影子之外，还没去过什么古迹。唯独到景山公园，因为没有预约被拒之门外，于是最近才想起来，这一圈下来更是勾起了我对明末朝代更替的追忆。
明朝末代皇帝是吊死在这里，相传崇祯自毁长城，冤杀大将袁崇焕，从此辽东天险不再，闯王起义入京，吴三桂一怒为红颜。大明王朝从此覆灭，留给后人的，只有无尽的断壁残垣而已。金庸的《碧血剑》则是以此为原型，讲述了一代江湖故事——从袁崇焕被冤杀开始，袁承志（历史无此人）为报仇而闯荡江湖，与闯王起义军一同推翻明朝，其间也夹杂着他与长平公主阿九一丝丝微妙的感情线。
近400年后，后人来此凭吊，除了明思宗殉国处的石碑外，其他的不过一棵歪脖老树而已。从他的死，我想到朱允炆，被四叔朱棣赶尽杀绝，大火中其死因成为千古谜团；又想到李煜，曾感叹“雕栏玉砌应犹在，只是朱颜改”；甚至，我还想到刘谌，蜀国城破之日，他杀妻杀子，最后在祠堂前自尽。自古以来，文死谏，武死战，反倒是皇帝们的死法各有不同。只是在小说的刻画里，崇祯已是穷途末路，走到煤山的尽头，结束了他悲剧的一生。而从整个景山公园的布局来看，崇祯大概是急匆匆从皇宫后门出来，然后在南门不远处，随便找了棵树草草吊死罢了，不知道他在最后一秒是否有回望，是否有“国破山河在”的感慨。
往北，是景山关帝庙，属于皇家，始建于明代，清朝移建重修。庙中的画布从桃园结义，大破黄巾开始，然后关羽斩颜良文丑，解白马之围，过五关斩六将，水淹七军，威震华夏，然后被奸人所害，身首异处。后来的人常常修缮关庙，以关羽的忠义原型，逐渐演变成武圣，大帝，于是简化为关帝。去年在武侯祠，我曾经发出了孙权后人是否拜会关帝是否合适的想法，现在大抵是知道了。
景山坐落在北京的中轴线上，其最北端，是历代皇帝祭祖的寿皇殿。这里曾供奉着清朝先祖的牌位，每逢大年初一或其他重要祭祀之日，皇帝便会亲临祭拜。殿内至今保留着神库、神厨等建筑，透过这些遗迹，我们得以追忆那些逝去的岁月，殿门前的树木，大多已有110年的树龄，默默见证着王朝的更迭与时代的变迁。
走出神道，商业街的喧嚣，不远处老大爷碎碎念，还有从山坡上传来的一群人合唱的声音。“旧时王谢堂前燕，飞入寻常百姓家”。大概是这个意思了吧。
吃过饭，继续往北，走过安定桥，去钟鼓楼，中轴线尽头是被改造成酒吧饭馆的宏恩观。
下个周末，去中轴线南面吧。
]]>本故事纯属虚构，请不要恶意解读。
我，比克，是被世人所误解的大魔王，在你们眼里烧杀抢掠，无恶不作。
在很早以前，我是本性善良的那美克星人，我的母星球民风淳朴，家家夜不闭户，路不拾遗。突然有一天，大长老说我太过年轻，需要过去历练，所以让我出去到处走走。
在浩瀚的宇宙中游荡，我的第一站是蓝白星球，说来惭愧，这也成了我的最后一站。由于人性的贪婪，自私，嗜血，自相残杀而导致我的本心在不断的被侵蚀，从此在这里沾染了邪念。我皮薄心软，而又太纯粹良善，面对这群人心不古的碳基生物便显得格格不入。
时间久了，所以我决定把我善良的一面完全分离出去，这样就不会有道德负罪，不会感受到痛苦，这是为了活下去，我的挣扎。让分离出来的善念去做天神，让他去制造属于地球的龙珠，然后借助龙珠的许愿把这里变成和娜美克星球一样的故乡。
原定分离的计划是，让他保持着最原本最初的样子，就是那种在我们那美克星被视为美德的仁慈和纯真，母星球的原住民们都喜欢以德报怨。在大长老的英明领导下，我们也不会滥用龙珠，所以几亿年也没有听过发生什么负向能源以及黑龙珠的故事。但是这里完全不同，大街上到处充斥着各种欲望和怨念的结合体，所以很早之前，我就讲这些隐患这些全盘托付，苦口婆心的告诉过以前的界王神，至于他被封印，那是后面的事情了。
最早以前我预言过魔人布欧的诞生，不过与他不同的是，他是邪恶念头的占据主体，完全依靠无意识的杀戮——而我与他不同，我选择不得不去剥离善良，只为把那些软弱、无知、脆弱以及同情的情绪，一并全都抛出去。这些在这个蓝白星球中不知不觉的产生的脆弱感情感，总会在不经意间会干扰我的思考的节律，以至于无意识的对他人进行评判或者怨恨。后来我明白了，不能对人产生感情。否则，我就不再是我。至少在我看来，当地的蓝白星人，倒像是战国时代旧物所积的怨念，借一把梳子、一缕头发便化形的妖怪，然后越俎代庖，李代桃僵，夺舍之后再假装自己就是这一代的天命人。
我并不反感这些由巨人身上跳蚤幻化的后来者，甚至在一开始有些迎合他们。你们喜欢杀戮，我就变成杀戮，你们喜欢肮脏，我就变成肮脏，你们喜欢毁灭，我就变成毁灭，他们不喜欢我，我也不喜欢自己，也逐渐对人认可宣扬比克大魔王这个称号，以至于到后来，我满世界的寻找屠杀武道家，只是为了测试我是否还沾染着脆弱的人类情感而已。到后来，代价太大，我已无力解释。你们都说我残忍，而为了活下去，我只好假装感受不到任何痛苦，放不低姿态所以无法共情。
你们蓝白球人喜欢讲，‘橘生淮南，’这又何尝不是。
当年与武泰斗巅峰一战，我早就已经厌倦了，他天资聪颖，自他出生起，我便在神殿看着他长大，我和他本不必走到如此的。而他漫天拳雨袭来，我本可以轻松的杀死他，于是假装漫不经心。而他要代表某种流派，我和他终究只是立场不同而已。战士骄傲的自尊心不允许我放水，在日日夜夜的战斗后，最终我被成功封印，武泰斗力竭阵亡。在此之后，他的后人龟仙与鹤徒各奔东西，于是树倒猢狲散，土徒子徒孙争斗不休。
在那平静如水的被封印的日子里，我每次苦思冥想，究竟错的是我，还是始终有一双无形的大手在恣意玩弄这一切？为了贯彻到底，于是我在佛前求了五百年，求他让我了结和武道家的尘缘。碳基人又执念太深，非要说他是正，我是邪，于是正邪不两立，双方争斗又不死不休，索性不如将天底下的罪孽都归我吧，这样的人留着上也是祸害，也省着伤害他人。所以后来你们不断的叫我魔王，比克大魔王，只是我心已死，是非我已无心辩驳。只要我不愿意，随时能够毁灭地球，就凭这一点你们就该对我感恩戴德，顶礼膜拜。这些愚蠢的碳基生物毕生的的愿望就是安家置业成居，然后安静的等待老死。而我是可以不死的，所以宁可不沾染庸俗。而你们，凭什么认为你们能够救赎我？
后来被孙悟空打败，我是释然了的，除去被封印的漫长的岁月里，我早就已经倦怠了，我需要一个结束自己的理由。但是倘若我死了神仙也会消失，我需要慎重考虑，第一次交手悟空与我实力悬殊，我是故意留了他一口气，就是想知道赛亚人是不是传说中的武道家，他是不是传说中可以打败弗利萨，然后的可以理解我的超级赛亚人。虽然我知道，为了对手的尊严不能放水，就像当初对战武泰斗一样，战士可以光明正大的战死，但是你不能。
后来我似是解脱了，悟空在超神水的帮助下打败了我。肌肉发达的他显然没有想过，我若死了，神仙也会一起消失。所以最后我吐出蛋，幻化出二代分身，就是为了让那个曾经我不顾一切分离出来的善念活下去。出于某种不可言状的目标，我给他留下的执念是打败孙悟空，同样也要探索在和武道家之前没有达成的共识。我不能因为我的原因造成神仙消失，同时还需要二代的我寻找最初的的执念，让他去继续探究作为一个人人喊打的异类，究竟应该以怎样的姿态活着？
弗利萨的到来是一个插曲，但是从某种意义来说，我和蓝白星有一段短暂的风花雪月。这群愚蠢的碳基生物虽常常忌惮我，总体也算是秋毫无犯。又发生了很多事，我们一起联手对抗了人造人，魔人布欧。沙鲁篇我和神仙又合二为一，我又找回了作为生物本能的情感，我说这是神仙大人的智慧。我亲自训练了悟饭，悟天克斯，甚至还有小芳。
最后的事你们都知道了，我变成了孙家保姆，悟饭亲爹。所以我也是一个拥有感情的人？假如有平行世界会好么？
]]>深夜好好想想，大概有以下几个问题吧：
不过似乎让他对症找医院还行。起码医保范围内多开点检查。
除非再人脑植入芯片可以像DMA一样做决策吧，不然日常生活AI话完全就是把日常碎片化。
再说为什么是卸载豆包，因为其他的也没用过，千问的奶茶也没喝到。
Gemma4 也出了离线的手机端，会好么？
我想过去科技化的日子了。
一个懂计算机组成原理、做AI相关产品工作、理性到会用DMA比喻决策困境的独居青年，在深夜和最后一个AI聊完天后，决定回到一个不需要向机器倾诉的世界——不是因为他恨技术，而是因为他太懂技术，知道技术给不了他真正想要的东西。
]]>懒猫的SSO是如下配置：
1 | - Issuer：https://name.heiyu.space/sys/oauth |
懒猫微服的SSO服务运行在5557 端口，通过 docker 网络访问地址是 172.18.0.2:5557。
可以先使用grpcurl来连接测试：
1 | ./grpcurl -plaintext 172.18.0.2:5557 list |
在这里下载GRPC：
https://github.com/fullstorydev/grpcurl/releases
gRPC 是一个跨语言、高性能的远程过程调用（RPC）框架，它强依赖 HTTP/2 协议，并默认使用 Protobuf 作为二进制序列化协议。它的核心优势在于利用 HTTP/2 的多路复用和头部压缩提升了性能，通过二进制传输减少了带宽消耗，并且通过强类型的接口定义保证了跨语言调用的严谨性。”
然后使用grpcurl对懒猫微服的SSO的API进行操作，因为是OIDC，所以这一步骤主要一个Oauth的应用， 也就是注册App name，client_id，client_secret，以及 redirect_uris。存储用的是内存 SQLite，容器重启后所有 OAuth token、授权码、已注册的 client 都会丢失。当然如果你想持久化的话，也可以写到systemd启动脚本让系统自启动拉起来。
1 | ./grpcurl -plaintext -d '{"client":{"id":"my-app","secret":"my-app-secret","redirect_uris":["http://localhost:8080/auth/callback"],"name":"My App"}}' 172.18.0.2:5557 api.Dex/CreateClient |
注册之后我们把这些信息放到authlib代码里面，把SSO串起来。
1 | from flask import Flask, redirect, url_for, session, jsonify |
这是一个用 Flask + authlib 对接 懒猫 SSO 的最小 OIDC 客户端应用：
整个流程就是标准的 OAuth2 Authorization Code Flow：用户点登录 → 跳 懒猫 SSO → 认证通过 → 回调拿 token → 存
session → 完成登录。
访问应用的时候，一开始会出现这个认证，这个是懒猫域名自带的认证，是为了应用放在公网的上的强制用户名密码认证，所以不要把他当作是我们本次懒猫SSO的主角。
这个才是正式的OpenID Connect，点击Grant Access，然后就可以进行认证了。
登录之后我们可以查看profile信息，以及登录之后token，这样就抓到了OIDC的去全部信息：
如果之前注册的是 localhost，但 Flask 默认用127.0.0.1 。所以会收到Unregistered redirect_uri 的错误。所以把域名改成localhost就好。
好了，以上就是如何超越系统注册，使用API建立自己的懒猫SSO应用了，这样我们就可以不必再依赖三方的IDP了。
Less is more。
]]>OpenID Connect 的提供商我选择了 Amazon 的 Cognito，然后对应的Dashboards（前端跳转）和 OpenSearch Security（后端验证）都要单独来做集成。
OIDC 是通用协议，Cognito 只是本文选的提供商，换 Keycloak、Okta、Auth0 都一样
在 Cognito 控制台创建一个 App Client,因为我做了端口映射，所以回调和注销的URL都是localhost：
http://localhost:5601/auth/openid/loginhttp://localhost:5601
记录下 Client ID、Client Secret、User Pool ID。
创建用户后，Cognito 会将用户状态设为”强制更改密码”，可以通过 AWS CLI 将密码设为永久：
1 | aws cognito-idp admin-set-user-password \ |
创建 dashboards-values.yaml，让 Dashboards 跳转到 Cognito 登录，其实就是配置OIDC的redirect_url，scope，client_id，client_secret 这些东西：
1 | opensearchHosts: "https://opensearch-cluster-master:9200" |
接下来使用helm进行部署：
1 | helm upgrade --install dashboards opensearch/opensearch-dashboards -f dashboards-values.yaml |
几个注意点：
config 字段会完全覆盖默认的 opensearch_dashboards.yml，不是合并。所以 server.host、opensearch.hosts 等基础配置必须写进去，否则 Dashboards 会启动失败opensearch.username/password 是 Dashboards 后端连接 OpenSearch 的服务账号（kibanaserver），即使用了 OIDC 登录也需要保留。OIDC 解决的是终端用户认证，kibanaserver 解决的是 Dashboards 进程和 OpenSearch 之间的后端通信Dashboards 配好后，用户能跳转到 Cognito 登录了，但 OpenSearch 集群还不认识 JWT Token，会返回 401。需要在 OpenSearch 的 Security 配置中添加 OIDC 认证域。
虽然 OpenSearch Helm chart 提供了 securityConfig 字段，理论上可以在 values.yaml 里注入安全配置。但实际上我的配置并没有成功，所以我使用了securityadmin 工具直接写入 security index的方式，这个办法不需要重启 OpenSearch，立即生效：
1 | kubectl exec -it opensearch-cluster-master-0 -- bash -c ' |
关键参数说明：
subject_key: email — 用 JWT 中的 email 字段作为用户名，而不是默认的 sub（一串 UUID）roles_key: cognito:groups — 从 Cognito 用户组映射 OpenSearch 角色basic_internal_auth_domain — 保留 Basic Auth，让 admin 用户和 Fluent Bit 等内部服务仍可用用户名密码认证securityadmin.sh 通过 TLS 客户端证书（kirk.pem）认证，直接操作底层索引，写入后 OpenSearch 自动热加载联合登陆的用户登录后默认没有任何权限，接下来需要做角色映射：
1 | { |
1 | curl -sk -X PUT https://localhost:9200/_plugins/_security/api/rolesmapping/all_access \ |
生产环境建议通过Single Sign On用户组来映射角色，而不是直接映射单个用户。
由于Pod在k8s集群里，所以我们使用kubectl做端口转发。
1 | kubectl port-forward svc/dashboards-opensearch-dashboards 5601:5601 |
浏览器打开 http://localhost:5601，应该会自动跳转到 Cognito 登录页面。
同样，OpenSearch也要做端口转发：
1 | kubectl port-forward svc/opensearch-cluster-master 9200:9200 |
然后就可以使用Python脚本来进行验证了，通过Cognito API得到JWT，然后在请求OpenSearch的时候在header里带上Authorization Header。
1 | import boto3, hmac, hashlib, base64, requests |
1 | # 1. 部署 OpenSearch（不带 securityConfig） |
感谢有了单点登录，让我们管理OpenSearch的时候更加丝滑～
]]>他除了穿着黑色的僧袍，剃了头发，余下的大致与常人没差，当然也用智能手机用微信，和常人一样搭乘火车出行。这事过去太久了，以至于忘记了和他聊起来的契机。大和尚问我是不是从事科技相关的工作，想让我帮他答疑手机卡顿的问题。
后面慢慢不知怎的就扯到了其他方面，大和尚开示给我讲人的念头到底多少多少，过午不食云云，甚至兴致上来对现在大学生礼崩乐坏周公之礼也评论一番，说孩子是孽，生来就是要赎罪，要用念佛号来压制大脑里浮起的念头。然后提倡我来教育这些年轻人。嗯 ，突然有被传教的感觉。剩下的就是不要杀生吃肉，因为蔬菜没有生命之类的话了。简单交流下来，只知道他这番话，这与我那时的所说修习的正念训练是不一致的，但是我不想争论。
这种话题自然会吸引到周围的人，他们亲切的称呼为和尚为大师，颇有唐僧见佛就拜的意味。而乘坐绿皮车的大多是普通的苦命人。晚上的车厢时而有觥筹交错，能听见酒鬼们的互相吹牛，而早上又被小孩子的哭闹声或者打游戏的声音吵醒，奶奶辈的啰嗦从来是不停的。甚至偶尔还需要乘务员来调节，乘务员对我说，我就在隔壁，如果车上发生了什么事，就过来找我。
这和尚讲的起劲，他又把刚才对我讲的话和车里这些人讲述了一遍。他甚至不忘时不时的补上一句，”这些不是我说的，是开悟的大和尚说的。“
在他的“粉丝团”里，比较典型的有个中年妇女，在我看来，她并不算面善，甚至脸上写满了祥林嫂式的生活。她说老公信佛，在家斋戒，当对外的应酬则很无奈，然后把陈年的烂谷子的事情都倒出来，求大师指点迷津。于是这和尚的布道由此而来，因此人愈来愈多，好像在争着赶集。
我前面所说，这一车大多是苦命人，被命运的车轮推动着做一些身不由己但力求活着的事情，他们忘了曾经的梦想，今日被惦记明日的言行念头所淹没，明日又会担忧后面的生活，或者干脆认命不再挣扎，承认这辈子就这样，就可以问心无愧从而得到一夕安寝。对他们来说，只要不违背公序良俗，再多的爱恨情仇，也不会触犯法律红线从而带来杀身之祸。倘若苍天有情，因为一个名不见经传和尚的三两闲言碎语就可以轻松改变，愚者开悟，恶人回头。那我之前坚持的善恶之辩又算是什么呢？
这些人的故事，让我想起了李碧华在《胭脂扣》中的一句话，在香港，任何一个凡俗的市民，毕生宏愿都是置业成家安居，然后老死。
但我不是在香港，是在北京。这里也是人生百态，比如餐馆里刚刚出狱的光头，在饭桌眉飞色舞的给同乡伙伴讲述是当时是如何声泪俱下的给狱警求情，甚至避免了在里面用纳税人的钱了过一辈子的事情。甚至还能听见富有二人组在讨论难以想象住宅楼被邻居的鸡飞狗跳所影响的生活，然后说这是是无法忍受的，要住就做别墅，再来一个小院，才是生活。然后继续对北京的某个菜系的难以下咽的继续滔滔不绝的吐槽。不知道这里啊是不是个明星，不过除非像杨紫一样来国贸办活动贴海报，否则就算线下遇到也绝对认不出来。
我已经无心再听和尚给他们”答疑解惑”了,他如果有什么手机电脑问题，倒是可以来找我请教。盘古开天辟地之后，眼睛变成了日月，血液变成了江河，身上的跳蚤变成了人类。从一朝闻道开始，想要被救赎还要身体力行吧。所以儒家讲：“非独贤者有是心也，人皆有之，贤者能勿丧耳。”，道家讲“知不可奈何而安之若命，唯有德者能之”。
他的朋友圈每天都在发重复的忏悔，好似应了他关于孩子是孽的论述，甚至包括他自己，也许他不再需要恪守托钵乞食，过午不食这一传统，剩下的只是做大众视野里和尚该做的事。我不爱看，所以屏蔽了。说不定哪天他去考取一个博士的学位，这一切才能够更加顺理成章吧。世人对于和尚的期许是普度众生，那和尚就可以删人微信吗？
我沉吟良久，这好似鲁迅《狂人日记》书缝里的字了，只是于我而言，看到的只有四个字 — 这不矛盾。
]]>本文假设你已经有一个运行中的 OpenSearch 集群，如果没有可以参考上一篇文章。
先部署一个简单的 Nginx 作为日志来源：
1 | kubectl create deployment nginx --image=nginx |
添加 Helm 仓库：
1 | helm repo add fluent https://fluent.github.io/helm-charts |
Fluent Bit 的配置比较长，建议用 values 文件管理。创建 fluent-bit-values.yaml：
1 | config: |
安装：
1 | helm install fluent-bit fluent/fluent-bit -f fluent-bit-values.yaml |
这里解释几个关键配置项：
1 | Exclude_Path /var/log/containers/fluent-bit*.log,/var/log/containers/opensearch*.log,/var/log/containers/dashboards*.log,/var/log/containers/*_kube-system_*.log |
这是我们踩过的一个坑。Fluent Bit 作为 DaemonSet 运行在每个节点上，默认会采集 /var/log/containers/ 下所有容器的日志。如果节点上跑了 OpenSearch、Dashboards 这些日志量很大的服务，Fluent Bit 的内存缓冲区（Mem_Buf_Limit 5MB）会很快被填满，导致其他日志（比如 Nginx）发送失败，表现为不断报 failed to flush chunk 错误。
另外特别要注意排除 Fluent Bit 自己的日志。如果开了 debug 模式，Fluent Bit 会疯狂输出日志，而这些日志又会被自己的 tail input 读取，形成死循环，直接把缓冲区撑爆。
1 | Logstash_Format On |
开启后索引名会变成 nginx-logs-2026.03.23 这样按天轮换，方便后续做索引生命周期管理。在 Dashboards 里创建 index pattern 时用 nginx-logs-* 即可匹配所有日期的索引。
1 | [FILTER] |
这个 filter 会自动给每条日志加上 kubernetes.pod_name、kubernetes.namespace_name、kubernetes.container_name 等字段，这样在 Dashboards 里就可以按 Pod 名称过滤日志了。
Nginx 在没有请求的时候不会输出 access log，需要手动访问一下：
1 | kubectl port-forward svc/nginx 8080:80 & |
我们能够看到已经馋看了nginx-log这个索引，并且按照时间轮换。
kubectl port-forward svc/dashboards-opensearch-dashboards 5601:5601）
nginx-logs-* 的 index pattern。
时间字段选 @timestamp
kubernetes.pod_name或者其他字段（我这里用的imaeg的名字），点击过滤即可按 Pod 查看日志
如果在 Available fields 里看不到 kubernetes 相关字段，去 Index Patterns 里点刷新按钮（🔄）刷新字段列表。
大概率是缓冲区被其他 Pod 的日志挤满了。用 Exclude_Path 排除不需要的日志，或者加大 Mem_Buf_Limit。
检查 Nginx Pod 所在节点的 Fluent Bit 是否正常。可能是那个节点的 Fluent Bit 启动时 OpenSearch 还没 ready，导致一直 flush 失败。删掉那个 Fluent Bit Pod 让 DaemonSet 重建即可。
确认 Fluent Bit output 配置里的 Host、Port、HTTP_User、HTTP_Passwd、tls 是否正确。可以用以下命令从集群内部测试连通性：
1 | kubectl run test-curl --image=curlimages/curl --rm -it --restart=Never -- curl -sk https://opensearch-cluster-master:9200 -u 'admin:<your-password>' |
Fluent Bit + OpenSearch 是 Kubernetes 上轻量级日志方案的经典组合。核心要点是合理配置 Exclude_Path 控制采集范围，避免无关日志挤占缓冲区。配合 Logstash_Format 做索引轮换，再加上 kubernetes filter 提供的 Pod 元数据，就能在 Dashboards 里方便地按 Pod、Namespace 等维度过滤和分析日志了。
一个从零开始的 Go 反向代理，分四个阶段进化成一个生产级 SRE 工具。每个阶段解决一类真实问题，边学语法边写功能。每周按 5 个工作日拆分，周末可以复习或补进度。
你原始规划里提到了”协议升级：把 HTTP 请求转成 gRPC”。简单解释一下这是什么。
gRPC 是 Google 搞的一个远程过程调用（RPC）框架。普通的 HTTP API 用 JSON 传数据，人能读懂但体积大、解析慢。gRPC 用一种叫 Protocol Buffers（protobuf）的二进制格式传数据，体积小、速度快，而且跑在 HTTP/2 上，天然支持多路复用和流式传输。
在微服务架构里，服务之间的内部通信经常用 gRPC 而不是 HTTP+JSON，因为性能好很多。代理做”协议升级”的意思是：外部客户端发普通 HTTP+JSON 请求进来，代理把它转成 gRPC 格式发给后端微服务。这样外部用户不需要知道后端用的是 gRPC，代理帮你做了翻译。
gRPC 和普通 HTTP API 的区别在于三个层面。传输层：普通 HTTP API 跑在 HTTP/1.1 上，一个连接同一时间只能处理一个请求；gRPC 跑在 HTTP/2 上，一个连接可以同时处理多个请求（多路复用）。序列化格式：普通 API 用 JSON（文本），gRPC 用 protobuf（二进制），同样的数据 protobuf 通常比 JSON 小 3-10 倍。接口定义：gRPC 用 .proto 文件严格定义接口，用 protoc 编译器自动生成代码，客户端和服务端的数据结构是编译时确定的。
gRPC 代理涉及 HTTP/2 帧处理、protobuf 序列化/反序列化、服务定义文件编译、动态反射调用等，复杂度比较高，放在第 13-14 周作为进阶目标。
这周不急着写代理，先把 Go 的基础语法打牢。
Day 1：环境搭建 + A Tour of Go（上）
安装 Go，配置好编辑器。打开 A Tour of Go（https://go.dev/tour/），过 Basics 部分：变量声明（var 和 :=）、基本类型（int、string、bool）、函数定义（func）、多返回值。不用全记住，有个印象就行。
Day 2：A Tour of Go（中）
继续过 Flow Control（for、if、switch）和 More Types 的前半部分（指针、struct）。Go 没有 while 循环，所有循环都用 for。struct 是 Go 里组织数据的核心方式，类似其他语言的 class 但没有继承。
Day 3：A Tour of Go（下）
过 More Types 的后半部分（slice、map、range）和 Methods and Interfaces 的前半部分。slice 和 map 会贯穿整个项目。如果 interface 看不懂没关系，后面第 9 周会专门学。
Day 4：第一个程序 + struct 和 json
关掉教程，自己写一个 main.go。定义一个 Config struct，包含 ListenPort int 和 TargetURL string 两个字段，加上 json tag（比如 `json:"listen_port"`）。创建一个 config.json 文件，用 os.ReadFile 读取，用 json.Unmarshal 映射到 struct，用 fmt.Println 打印出来。确认 go run main.go 能跑通。
Day 5：错误处理 + 练习
Go 的错误处理模式是 if err != nil { log.Fatal(err) }，从今天开始习惯它。给 Day 4 的代码加上完整的错误处理：文件不存在怎么办、JSON 格式错误怎么办。然后做个小练习：改 config.json 的内容，故意写错 JSON 格式，看程序怎么报错。学会用 log.Printf 输出带格式的日志。
Day 1：启动一个 HTTP 服务器
学 net/http 包。用 http.HandleFunc("/", handler) 注册一个处理函数，用 http.ListenAndServe(":8080", nil) 启动服务器。handler 函数的签名是 func(w http.ResponseWriter, r *http.Request)，先让它返回一个固定字符串 “hello proxy”。用 curl localhost:8080 验证。
Day 2：理解 http.Request 和 http.ResponseWriter
在 handler 里打印请求的各种信息：r.Method（GET/POST）、r.URL.Path（路径）、r.Header（所有请求头）、r.RemoteAddr（客户端地址）。用 w.WriteHeader(200) 设置状态码，用 w.Write([]byte("hello")) 写响应体。用 curl 发不同的请求（GET、POST、带 Header），观察打印结果。
Day 3：用 http.Client 发送请求
学 http.NewRequest 构造请求和 http.Client{} 的 Do 方法发送请求。写一个小程序：向 http://httpbin.org/get 发 GET 请求，打印响应状态码和 Body。理解 resp.Body 是一个 io.ReadCloser，必须用 defer resp.Body.Close() 关闭。
Day 4：实现请求转发
把前几天学的串起来：handler 收到请求后，用 http.NewRequest 构造一个新请求（方法、URL、Body 都从原始请求复制），用 http.Client 发送到 config.json 里配置的目标地址，用 io.Copy(w, resp.Body) 把上游响应写回客户端。
Day 5：处理请求头复制 + 测试
转发时还需要把原始请求的 Header 复制到新请求上（遍历 r.Header，逐个 Set 到新请求）。同时把上游响应的 Header 也复制回客户端。用 curl localhost:8080/get 测试，确认返回的内容和直接访问 httpbin.org/get 一样。这就是一个能跑的最简代理了。
Day 1：伪装 Host
在转发逻辑里，转发之前加两行：req.Header.Set("Host", targetHost) 和 req.Host = targetHost。这样目标服务器看到的 Host 头就是你指定的值，而不是 localhost:8080。用 httpbin.org/headers 验证：转发后返回的 headers 里 Host 应该是 httpbin.org。
Day 2：理解 TLS/HTTPS + 生成自签名证书
花半天理解 HTTPS 的工作原理：客户端和服务器通过 TLS 握手协商加密方式，服务器出示证书证明身份，之后所有数据加密传输。”HTTPS 卸载”的意思是代理对外提供 HTTPS，对内用 HTTP 转发给后端。然后用 openssl 生成自签名证书：openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes。
Day 3：启动 HTTPS 服务器
学 crypto/tls 包，用 tls.LoadX509KeyPair("cert.pem", "key.pem") 加载证书。把 http.ListenAndServe 换成 http.ListenAndServeTLS(":8443", "cert.pem", "key.pem", nil)。用 curl -k https://localhost:8443/get 测试（-k 跳过证书验证）。转发到后端仍然用 HTTP，HTTPS 卸载完成。
Arch Linux 提示：你可以用
mkcert代替 openssl 生成证书（pacman -S mkcert）。mkcert 会自动创建一个本地信任的 CA 并安装到系统信任链里，生成的证书浏览器和 curl 都不会报红，测试时不需要-k参数。运行mkcert -install初始化 CA，然后mkcert localhost 127.0.0.1生成证书。
Day 4：同时监听 HTTP 和 HTTPS
实际场景中代理可能需要同时提供 HTTP（8080）和 HTTPS（8443）。用两个 goroutine 分别启动两个服务器：go http.ListenAndServe(...) 和 http.ListenAndServeTLS(...)。这里会第一次用到 goroutine，但很简单，就是在函数调用前加个 go。
Day 5：学习 httputil.ReverseProxy + 回顾
Go 标准库自带了 net/http/httputil.ReverseProxy，它就是一个现成的反向代理实现。读一下它的源码（不长），理解它怎么处理请求复制、响应转发、错误处理。对比你自己写的转发逻辑，看看有什么可以改进的。不需要替换你的代码，理解思路就行。回顾这三周的代码，整理一下结构。
这周比较有挑战，不要急。
Day 1：理解 WebSocket 协议
不写代码。WebSocket 通过一次 HTTP 升级握手（Upgrade: websocket）建立连接后，双方可以随时互发消息，连接一直保持。适合聊天、实时推送这类场景。用浏览器开发者工具打开一个 WebSocket 网站（比如 websocket.org 的 echo 测试），观察握手过程和消息收发。
Day 2：搭建 WebSocket 测试服务
安装 gorilla/websocket 库（go get github.com/gorilla/websocket），这里会学到 go get 安装第三方库和 go.mod 依赖管理。写一个最简单的 WebSocket echo 服务器：客户端发什么，服务端原样返回。安装 wscat（npm install -g wscat）测试连接。
Day 3：学习 http.Hijacker 接口
http.Hijacker 能从 HTTP 连接中”劫持”底层的 TCP 连接。调用 w.(http.Hijacker).Hijack() 后，你拿到的是一个裸的 net.Conn，HTTP 层不再管这个连接了。写一个小例子：收到请求后 Hijack 连接，直接往 TCP 连接上写一段文字，用 curl 观察效果。
Day 4：实现 WebSocket 代理转发
代理收到 WebSocket 升级请求后，先向后端建立 WebSocket 连接，然后用两个 goroutine 做双向转发：一个从客户端读数据写到后端，一个从后端读数据写到客户端。用 wscat 通过代理连接 Day 2 的 echo 服务，验证双向通信。
Day 5：错误处理 + 连接关闭
处理各种边界情况：客户端断开时关闭后端连接，后端断开时通知客户端。加上日志，打印 WebSocket 连接的建立和关闭事件。如果 Day 4 没搞定，今天继续调试，不要急着往下走。
原来的鉴权和过滤分了两周，但 Token 鉴权和 UA 黑名单的语法很简单（就是 if-else 和 slice 遍历），所以压缩成一周，把省下来的时间给内容过滤和动态路由多留一天缓冲。
Day 1：学 slice 和 for…range + 实现 Token 鉴权
Go 的 slice（切片）是动态数组，用 []string{"a", "b"} 创建，用 len() 获取长度，用 append() 添加元素，用 for i, v := range slice 遍历。在 config.json 里加一个 "token": "my-secret-token" 字段。在转发逻辑的最前面加检查：r.Header.Get("X-Token") 读取请求头，不等于配置里的 token 就返回 403。用 curl -H "X-Token: my-secret-token" localhost:8080/get 测试通过，不带 header 测试返回 403。
Day 2：实现 UA 黑名单
在 config.json 里加 "ua_blacklist": ["BadBot", "Scrapy"]。读取请求的 User-Agent 头，用 for...range 遍历黑名单，用 strings.Contains（配合 strings.ToLower 做大小写不敏感匹配）检查 UA 是否包含黑名单关键词。命中就返回 403。把鉴权和 UA 检查抽成独立函数：func checkToken(r *http.Request, token string) bool 和 func checkUA(r *http.Request, blacklist []string) bool，保持 handler 干净。
Day 3：学 map + bytes 包 + 理解 Body 一次性读取问题
Go 的 map[string]string 是键值对集合，用 m[key] 读取，用 for k, v := range m 遍历。然后理解一个关键问题：HTTP 请求的 Body 是一个 io.ReadCloser，只能读一次。读完之后如果还要转发，必须用 bytes.NewReader(bodyBytes) 重新包装成一个新的 Reader 赋回 r.Body。写个小例子验证这个行为。
Day 4：实现内容过滤（敏感词拦截）
在 config.json 里加 "sensitive_words": ["password", "secret"]。在转发之前，用 io.ReadAll(r.Body) 读取整个 Body，用 bytes.Contains 检查是否包含敏感词。如果包含，返回 400。如果不包含，用 bytes.NewReader(bodyBytes) 重新包装 Body 继续转发。用 curl -X POST -d "my password is 123" localhost:8080/post 测试拦截。
Day 5：测试所有安检功能
同时测试 Token 鉴权、UA 黑名单、内容过滤的各种组合：不带 Token、带错误 Token、带正确 Token 但 UA 在黑名单里、Token 和 UA 都通过但 Body 有敏感词。加上日志，打印每个被拒绝的请求的原因。确保所有情况都正确处理。
原来路由和负载均衡分了两周，但路由的核心就是 map + 前缀匹配，负载均衡的核心就是取模运算，合并到一周刚好。
Day 1：实现动态路由
把 config.json 的单个 target_url 改成路由表："routes": {"/api": "http://backend-a:8080", "/static": "http://backend-b:8080"}。在 handler 里用 strings.HasPrefix(r.URL.Path, prefix) 遍历路由表找到匹配的后端。注意 map 遍历顺序是随机的，所以把路由前缀放进一个 slice 里按长度从长到短排序，先匹配最具体的路由。加一个默认路由兜底。
Day 2：学方法（method）和指针 + 定义 LoadBalancer struct
Go 的 struct 可以绑定方法：func (lb *LoadBalancer) Next() string。*LoadBalancer 是指针接收者，方法可以修改 struct 的字段。如果用值接收者，每次调用都是在副本上操作，修改不会生效。定义一个 LoadBalancer struct，包含 backends []string 和 counter int64，写一个 Next() 方法返回 backends[counter % len(backends)] 并递增 counter。
Day 3：用 atomic 实现并发安全 + 改造路由表
学 sync/atomic 包，把 counter++ 换成 atomic.AddInt64(&lb.counter, 1)。然后改造 config.json 的路由表，支持多后端："routes": {"/api": ["http://pod1:8080", "http://pod2:8080", "http://pod3:8080"]}。Config struct 对应改成 Routes map[string][]string。每个路由前缀对应一个 LoadBalancer 实例。
Day 4：集成到代理 + 测试轮询
在 handler 里先匹配路由，再调用对应 LoadBalancer 的 Next() 获取后端地址。启动 3 个简单后端（分别返回 “I am pod1”、”I am pod2”、”I am pod3”），用 for i in {1..9}; do curl localhost:8080/api; done 连续请求 9 次，确认响应依次是 pod1、pod2、pod3 循环。
进阶思考：基础的 Round Robin 假设所有后端性能一样，但 SRE 场景下后端节点性能不一是很常见的。如果有余力，可以尝试实现加权轮询（Weighted Round Robin）——在 config.json 里给每个后端配一个权重，权重高的分到更多请求。或者实现最少连接（Least Connections）——每次选当前活跃连接数最少的后端。这两个算法不复杂，但能让你的代理在真实场景下更实用。不急，可以留到 12 周收尾时再加。
Day 5：整合测试阶段一和阶段二
这是一个里程碑。同时验证所有已完成的功能：HTTPS 卸载、Host 伪装、WebSocket 转发、Token 鉴权、UA 黑名单、内容过滤、动态路由、轮询负载均衡。整理代码结构，把不同功能拆到不同的 .go 文件里（比如 auth.go、router.go、loadbalancer.go）。
这是整个路线里最陡的坡，goroutine、channel、select、context、Mutex 集中在这里。原来 2 周，现在给 3 周，多出来的一周用来消化并发模型。
Day 1：学 goroutine 基础
goroutine 是 Go 的轻量级线程，用 go func() { ... }() 启动。写几个小练习：启动 5 个 goroutine 分别打印不同的数字，观察输出顺序是随机的。理解 time.Sleep 可以让 goroutine 等待，但主 goroutine 退出后所有子 goroutine 都会被杀掉。
Day 2：学 channel 基础
channel 是 goroutine 之间传递数据的管道。ch := make(chan int) 创建无缓冲 channel，ch <- 42 发送（会阻塞直到有人接收），v := <-ch 接收（会阻塞直到有人发送）。写一个小练习：一个 goroutine 往 channel 发 10 个数字，主 goroutine 接收并打印。然后学带缓冲的 channel：ch := make(chan int, 5)，缓冲没满时发送不阻塞。
Day 3：学 select + time.Ticker
select 同时监听多个 channel，谁先有数据就执行谁的分支，类似 switch 但用于 channel。time.Ticker 是一个定时器，ticker := time.NewTicker(time.Second) 每秒往 ticker.C 这个 channel 发一个信号。写一个小程序：用 select 同时监听一个 ticker（每秒打印 “tick”）和一个 quit channel（收到信号就退出）。
Day 4：学 sync.Map + 实现限流器核心逻辑
sync.Map 是并发安全的 map，不需要手动加锁。用 m.Store(key, value) 存，m.Load(key) 取，m.Range(func(k, v) bool { ... }) 遍历。创建一个 RateLimiter struct，内部用 sync.Map 存储每个 IP 的请求计数。Allow(ip string) bool 方法：读取当前计数，超过 5 就返回 false，否则加 1 返回 true。启动一个 goroutine 监听 Ticker，每秒清零所有计数。
Day 5：集成限流器到代理 + 测试
用 net.SplitHostPort(r.RemoteAddr) 提取客户端 IP，调用 limiter.Allow(ip)，返回 false 就响应 429 Too Many Requests。用 ab -n 100 -c 10 http://localhost:8080/api 压测，观察日志确认同一个 IP 每秒只有前 5 个请求通过。
Day 1：理解熔断器状态机
不写代码，先在纸上画状态图。三种状态：Closed（关闭，正常转发）→ 连续错误超过阈值 → Open（打开，直接返回 503）→ 等待超时到期 → Half-Open（半开，放一个请求试探）→ 试探成功回到 Closed，失败回到 Open。理解每个状态转换的触发条件。
Day 2：学 sync.Mutex + 定义 CircuitBreaker struct
sync.Mutex 是互斥锁，mu.Lock() 加锁，mu.Unlock() 解锁，通常配合 defer mu.Unlock() 使用。定义一个 CircuitBreaker struct，包含：state string（当前状态）、failCount int（连续失败次数）、threshold int（阈值，比如 10）、lastFailTime time.Time、timeout time.Duration（恢复等待时间，比如 60 秒）、mu sync.Mutex。
Day 3：学 context.WithTimeout + 实现 Allow 和 RecordResult
context.WithTimeout 给操作设超时：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，别忘了 defer cancel()。实现 Allow() bool：Closed 状态返回 true；Open 状态检查是否超过 timeout，超过了切到 Half-Open 返回 true，没超过返回 false；Half-Open 状态返回 true（放一个请求试探）。实现 RecordResult(success bool)：成功则重置 failCount 切到 Closed；失败则递增 failCount，超过阈值切到 Open。
Day 4：集成到代理
在转发逻辑里加入熔断器：转发前调用 cb.Allow()，返回 false 就直接响应 503 “系统繁忙”。转发请求时用 req.WithContext(ctx) 加上 5 秒超时。转发后根据响应状态码调用 cb.RecordResult(statusCode < 500)。
Day 5：测试熔断和恢复
启动后端，正常请求确认通过。关掉后端，连续发请求，观察日志：前 10 个请求报错，第 11 个开始直接返回 503。等 60 秒后再发请求，观察半开状态的试探行为。重启后端，确认代理自动恢复转发。如果有 bug，今天调试。
这周节奏放缓，消化前两周的并发知识，同时开始做可观测性。
Day 1：并发复习
回顾 goroutine、channel、select、Mutex 的用法。重新读一遍限流器和熔断器的代码，确保每一行都理解。如果有不清楚的地方，去 Go by Example（https://gobyexample.com/）查对应的例子。
Day 2：学 defer + time 包做耗时统计
defer 在函数退出时执行，不管是正常 return 还是 panic。在 handler 开头写 start := time.Now()，然后 defer func() { log.Printf("[%s] %s → %d (%v)", r.Method, r.URL.Path, statusCode, time.Since(start)) }()。注意 statusCode 需要用一个自定义的 ResponseWriter 包装器来捕获（因为标准的 ResponseWriter 写完状态码后你读不回来）。
Day 3：写一个 StatusCapture ResponseWriter
定义一个 struct 包装 http.ResponseWriter，重写 WriteHeader 方法来记录状态码。这里会更深入理解 Go 的 interface：你的 struct 只要实现了 http.ResponseWriter 的三个方法（Header()、Write()、WriteHeader()），就可以当 ResponseWriter 用。
Day 4：学 interface + 理解 http.Handler
Go 的 http.Handler 接口只有一个方法：ServeHTTP(w http.ResponseWriter, r *http.Request)。任何实现了这个方法的 struct 都自动满足接口，不需要显式声明。理解中间件模式的签名：func(next http.Handler) http.Handler——接收一个 Handler，返回一个新的 Handler。
Day 5：写第一个中间件（Logging）
把 Day 2 的耗时统计逻辑封装成一个中间件函数。在调用 next.ServeHTTP(w, r) 之前记录开始时间，之后计算耗时并打印。验证中间件能正确包装现有的 handler。
Day 1：引入 Prometheus 客户端库
运行 go get github.com/prometheus/client_golang/prometheus 和 go get github.com/prometheus/client_golang/prometheus/promhttp。注册两个指标：一个 Counter proxy_requests_total（按状态码和路径分标签），一个 Histogram proxy_request_duration_seconds（记录延迟分布）。在 Logging 中间件里调用 counter.Inc() 和 histogram.Observe(elapsed.Seconds())。
Day 2：暴露 /metrics 端点 + 验证
用 http.Handle("/metrics", promhttp.Handler()) 暴露指标端点。启动代理，发几个请求，然后 curl localhost:8080/metrics 查看输出。你应该能看到 Prometheus 格式的指标数据。如果你的 K3s 集群里跑着 Prometheus，可以配置它来抓取这个端点。
Day 3：学 database/sql + 连接 SQLite
Go 的 database/sql 是标准库的数据库接口，具体数据库通过驱动实现。先用 SQLite（轻量，不需要装数据库服务）：go get github.com/mattn/go-sqlite3。用 sql.Open("sqlite3", "./proxy.db") 连接，用 db.Exec 创建一张 request_logs 表（字段：id、timestamp、method、url、status_code、duration_ms、request_body）。
避坑：SQLite 在并发写时会报
database is locked错误。你的代理是高并发的，必须在连接后设置db.SetMaxOpenConns(1)限制为单连接，让写操作排队。这能解决问题但会成为瓶颈。如果后续发现 SQLite 扛不住，可以换成 PostgreSQL（驱动用github.com/jackc/pgx/v5/stdlib），连接字符串改一下就行，database/sql的接口是通用的，业务代码几乎不用改。
Day 4：学 io.TeeReader + 实现同步写库
io.TeeReader(r, w) 返回一个 Reader，从它读取数据时，数据会同时写入 w。用它复制请求 Body：var bodyBuf bytes.Buffer，teeReader := io.TeeReader(r.Body, &bodyBuf)。转发完成后，用 db.Exec("INSERT INTO request_logs ...") 把请求信息写入数据库。先做同步写，验证数据能正确存入。
Day 5：用带缓冲 channel 改成异步写库
同步写库会拖慢请求。创建 logCh := make(chan LogEntry, 1000)，handler 里把日志条目扔进 channel 就返回，另一个 goroutine 从 channel 取数据写库。用 select 加 default 分支处理 channel 满的情况——丢弃日志而不是阻塞请求。加一个 Prometheus Counter 记录丢弃数量。
Day 1：理解流量镜像的原理
流量镜像就是把线上请求复制一份发到测试环境。生产后端正常处理并返回响应给客户端，测试后端也收到一模一样的请求但响应被丢弃。关键原则：镜像是”发了就忘”（fire and forget），镜像失败不能影响正常请求。
Day 2：用 bytes.Buffer 复制请求 Body
用 io.ReadAll(r.Body) 把 Body 读出来存到 []byte，然后用 bytes.NewReader(bodyBytes) 分别创建两个 Reader——一个给正常转发，一个给镜像请求。在 config.json 里加 "mirror_target": "http://test-backend:8080"。
Day 3：用 goroutine 异步发送镜像请求
用 http.NewRequest 构造一个新请求（复制方法、URL、Header、Body），go sendMirror(mirrorReq) 异步发送。主流程不等待镜像结果。给镜像请求用 context.WithTimeout 设独立的 3 秒超时。
Day 4：学 recover + 保护镜像 goroutine
recover 能捕获 goroutine 里的 panic。在镜像 goroutine 开头加 defer func() { if r := recover(); r != nil { log.Printf("mirror panic: %v", r) } }()，防止镜像崩溃影响主进程。
Day 5：测试镜像功能
启动两个后端：一个”生产”后端返回正常响应，一个”测试”后端只打印收到的请求。发请求到代理，确认客户端收到生产后端的响应，同时测试后端也出现了请求日志。关掉测试后端，确认镜像失败不影响正常响应。
Day 1：把所有功能重构为中间件
把鉴权、限流、UA 黑名单、内容过滤、Prometheus 指标、日志等逻辑都重构成独立的中间件函数，签名统一为 func(next http.Handler) http.Handler。比如 func TokenAuth(token string) func(http.Handler) http.Handler，检查 Token 不通过就返回 403，通过就调用 next.ServeHTTP(w, r)。
Day 2：串联中间件链
写一个 Chain 函数把多个中间件串起来。最终效果：请求依次经过 日志 → Prometheus → 限流 → Token 认证 → UA 黑名单 → 内容过滤 → 路由 → 负载均衡 → 熔断 → 转发。每一层都可以决定继续传递还是直接返回错误。
Day 3：学 flag 包 + 命令行参数
用 flag 包支持命令行参数：--config 指定配置文件路径，--port 指定监听端口。调用 flag.Parse() 解析。这样启动代理时可以 ./proxy --config /etc/proxy/config.json --port 9090。
Day 4：实现优雅关闭（Graceful Shutdown）
用 os/signal 监听 SIGINT 和 SIGTERM。收到信号后调用 server.Shutdown(ctx) 停止接受新连接，等待在途请求处理完再退出。同时关闭数据库连接、停止日志 goroutine。
Docker 化：写一个多阶段构建（Multi-stage Build）的 Dockerfile。第一阶段用
golang:1.22编译，第二阶段用scratch或gcr.io/distroless/static作为底座，只复制编译好的二进制文件进去。Go 编译出来的是静态链接的单文件，打包出来的镜像可能只有 10-15MB。然后docker build -t go-proxy .构建，docker run -p 8080:8080 go-proxy运行，确认代理在容器里正常工作。这个镜像可以直接推到你的 K3s 集群里跑。
Day 5：写单元测试 + 最终验收
学 testing 包。给限流器的 Allow() 写测试：连续调用 6 次，前 5 次返回 true 第 6 次返回 false。给熔断器写测试：连续 RecordResult(false) 超过阈值后 Allow() 返回 false。给轮询写测试：3 个后端调用 6 次，每个出现 2 次。用 go test ./... 运行。然后做一次完整的端到端验收。
不需要重写代理。是在已有的中间件链和路由系统上加一个新的路由规则：当请求路径匹配 /grpc/... 时，走 gRPC 转发 handler；其他路径还是走原来的 HTTP 转发。限流、鉴权、Prometheus 指标这些中间件照常工作，gRPC 转换只是在链的末端替换了转发方式。
Day 1：安装 protoc + 写第一个 .proto 文件
安装 Protocol Buffers 编译器（macOS 用 brew install protobuf），安装 Go 插件（go install google.golang.org/protobuf/cmd/protoc-gen-go@latest 和 go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest）。写一个 greeter.proto，定义一个 Greeter 服务，有一个 SayHello 方法，请求参数是 name（string），返回值是 message（string）。
Day 2：生成 Go 代码 + 写 gRPC 服务端
运行 protoc --go_out=. --go-grpc_out=. greeter.proto 生成两个 .go 文件。写一个 gRPC 服务端：实现生成的接口，用 grpc.NewServer() 创建服务器，监听 50051 端口。学 google.golang.org/grpc 这个核心库。
Day 3：写 gRPC 客户端 + 验证通信
写一个 gRPC 客户端：用 grpc.Dial 连接服务端，调用 SayHello 方法。运行服务端和客户端，确认通信正常。理解完整链路：.proto 定义 → protoc 生成代码 → 服务端实现 → 客户端调用。
Day 4：学 JSON ↔ protobuf 转换
学 google.golang.org/protobuf/encoding/protojson 包。protojson.Unmarshal 把 JSON 转成 protobuf 消息，protojson.Marshal 把 protobuf 转回 JSON。写个小程序验证：JSON {"name": "world"} → protobuf HelloRequest → JSON，确认数据一致。
Day 5：学 gRPC 反射 + grpcurl
gRPC 反射让代理在运行时查询后端支持哪些方法和参数结构，不需要编译时知道 .proto 定义。在 gRPC 服务端开启反射（reflection.Register(server)）。安装 grpcurl（brew install grpcurl），用它测试：grpcurl -plaintext localhost:50051 list 列出服务，grpcurl -plaintext -d '{"name": "world"}' localhost:50051 greeter.Greeter/SayHello 调用方法。
Day 1：学动态调用 API
学 google.golang.org/grpc 的 Invoke 方法和 google.golang.org/protobuf/types/dynamicpb 包。dynamicpb 允许在不 import 生成代码的情况下，根据运行时获取的服务描述符动态构造 protobuf 消息。这是通用 gRPC 代理的关键。
性能考量：动态反射转换（JSON ↔ Protobuf）虽然通用，但每次请求都要通过反射查询服务描述符，性能开销很大。可以加一个 LRU Cache（用
github.com/hashicorp/golang-lru或自己用sync.Map+ 链表实现），缓存已经解析过的服务描述符和方法描述符。第一次请求某个方法时走反射，之后直接从缓存取，减少反射频率。
Day 2：在代理中加 gRPC 路由
加一个新路由规则 /grpc/<service>/<method>。当请求匹配时：读取 JSON Body → 通过反射获取目标方法的描述符 → 用 protojson.Unmarshal 转成动态 protobuf 消息 → 用 grpc.Invoke 发送到后端 → 把 protobuf 响应用 protojson.Marshal 转回 JSON → 返回给客户端。
Day 3：处理 gRPC 错误码映射
gRPC 有自己的错误码（NotFound、Internal、Unavailable 等），需要映射到 HTTP 状态码：NotFound → 404，Internal → 500，Unavailable → 503。学 google.golang.org/grpc/status 包提取错误码。
Day 4：端到端测试
启动 gRPC 后端（开启反射），启动代理。用 curl -X POST -d '{"name": "world"}' localhost:8080/grpc/greeter.Greeter/SayHello 发送 HTTP+JSON 请求，确认代理翻译成 gRPC 发给后端，再翻译回 JSON 返回。客户端全程只用了 HTTP 和 JSON。
Day 5：最终收尾
验证 gRPC 路由和 HTTP 路由共存：/grpc/... 走 gRPC 转发，其他路径走 HTTP 转发。确认中间件链（限流、鉴权、Prometheus）对两种路由都生效。整理代码，更新 README。
1 | 阶段一：隐身斗篷（透明代理 / 协议转换）— 4 周 |
14 周后你手里会有一个能伪装 Host、能卸载 HTTPS、能转发 WebSocket 和 gRPC、能鉴权、能过滤、能路由、能负载均衡、能限流、能熔断、能出 Prometheus 指标、能全量记录日志、能镜像流量的 Go 代理——装进你封装的 Linux 发行版里，就是一套完整的自动化运维体系。
]]>本文基于 k3s + Easysearch 2.0.3 实测验证，从零开始搭建一套完整的日志收集方案。
Fluent Bit 是一个轻量级的日志收集和转发工具，用 C 语言写的，内存占用极低（通常只需要几十 MB）。它的工作很简单：从某个地方读日志（INPUT），可选地处理一下（FILTER），然后发到某个地方（OUTPUT）。
1 | INPUT → FILTER → OUTPUT |
常见用法：
tail 插件，类似 tail -f）和 Fluentd 的区别：Fluent Bit 更轻量（C 语言 vs Ruby），适合作为 Agent 部署在每个节点或 Pod 里。Fluentd 功能更丰富，适合做日志聚合层。在 Kubernetes 场景下，Fluent Bit 是更常见的选择。
INFINI Easysearch 是兼容 Elasticsearch API 的搜索引擎。Fluent Bit 的 es（Elasticsearch）输出插件可以直接对接，不需要改配置。简单理解：Easysearch 是 Elasticsearch 的国产替代品。
本文用 Sidecar 模式部署 Fluent Bit：把它和 Nginx 放在同一个 Pod 里，共享日志目录。
另一种常见方式是 DaemonSet 模式：在每个节点上跑一个 Fluent Bit，收集该节点上所有 Pod 的 stdout 日志。DaemonSet 适合收集所有 Pod 的日志，Sidecar 适合收集特定应用的日志文件。
1 | Nginx Pod |
1 | curl -sfL https://get.k3s.io | sh - |
1 | curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash |
Easysearch（基于 Lucene）需要较高的 mmap 限制：
1 | sudo sysctl -w vm.max_map_count=262144 |
更新helm仓库并且初始化cert-manager。
1 | helm repo add infinilabs https://helm.infinilabs.com |
1 | kubectl create namespace es |
⚠️ 密码必须包含至少 2 类字符（大写/小写/数字/特殊字符），否则初始化会失败，Pod 直接 Exit Code 1 崩溃。
1 | kubectl create secret generic easysearch-secrets \ |
使用厂家提供了helm Chart安装Easysearch，并且通过变量设置image的版本，截止目前，最新版本是2.0.3-2534。
1 | helm repo add infinilabs https://helm.infinilabs.com --force-update |
然后就是等 Pod Running：
1 | kubectl get pods -n es -w |
1 | kubectl port-forward -n es pod/easysearch-0 9200:9200 & |
返回 JSON 集群信息即成功：
1 | { |
如果你的机器内存比较小（< 4G）或者使用其他 storageClassName 需要修改配置：
1 | helm install easysearch infinilabs/easysearch -n es \ |
这个 YAML 包含三个 Kubernetes 资源（用 --- 分隔）：
fluent-bit.confhttp://nginx:80 访问 Nginx1 | cat << 'EOF' > nginx-fluentbit.yaml |
1 | # 部署 |
确认 Pod 里两个容器都 Running（READY 2/2）：
1 | kubectl get pods |
ConfigMap 部分（Fluent Bit 配置）：
| 字段 | 值 | 说明 |
|---|---|---|
[SERVICE] Flush | 3 | 每 3 秒把缓冲区的日志刷到 OUTPUT |
Log_Level | info | Fluent Bit 自身的日志级别 |
Daemon | off | 前台运行，容器里必须前台否则容器会退出 |
[INPUT] Name | tail | 类似 tail -f，实时跟踪文件新增内容 |
Tag | nginx.access | 给输入打标签，OUTPUT 用 Match 匹配 |
Path | /var/log/nginx/access.log | 要读的日志文件路径 |
DB | /var/log/flb_nginx.db | SQLite 文件，记录读到哪一行了，重启不重复读 |
Mem_Buf_Limit | 5MB | 内存缓冲区上限，防止日志太多撑爆内存 |
Refresh_Interval | 5 | 每 5 秒检查文件是否有新内容 |
[OUTPUT] Name | es | Elasticsearch 兼容输出插件，Easysearch 直接可用 |
Match | * | 匹配所有 Tag 的日志 |
Host | easysearch.es.svc.cluster.local | Easysearch 的 Service DNS（集群内访问） |
HTTP_User/Passwd | admin/Admin123 | Easysearch 认证信息 |
tls | Off | 不用 HTTPS（本版本默认 HTTP） |
Logstash_Format | On | 按日期创建索引，格式：nginx-logs-2026.03.11 |
Logstash_Prefix | nginx-logs | 索引名前缀 |
Retry_Limit | False | 发送失败无限重试 |
Suppress_Type_Name | On | 兼容 ES 7.x+，不发送 _type |
⚠️ Fluent Bit 的 ini 格式不支持行内注释！
Flush 3 # 注释会把3 # 注释整个当成值，导致解析失败。
Deployment 部分（两个容器 + 共享卷）：
| 字段 | 说明 |
|---|---|
containers[0]: nginx | Nginx 容器，处理 HTTP 请求，日志写到 /var/log/nginx/access.log |
containers[1]: fluent-bit | Sidecar 容器，读取 nginx 的日志文件发送到 Easysearch |
volumeMounts: nginx-logs | 两个容器都挂载这个卷，共享 /var/log/nginx 目录 |
readOnly: true | Fluent Bit 只读挂载，最小权限原则 |
volumeMounts: config | 把 ConfigMap 挂载为 Fluent Bit 的配置文件目录 |
volumes: nginx-logs (emptyDir) | 临时卷，Pod 内容器共享，Pod 删除后数据丢失 |
volumes: config (configMap) | 引用上面的 ConfigMap |
1 | 同一个 Pod |
为什么用 emptyDir？
emptyDir 是一个临时卷，在 Pod 创建时自动创建，Pod 删除时自动清理。它的作用是让同一个 Pod 里的多个容器共享文件。nginx 写日志到这个目录，fluent-bit 从这个目录读日志。
为什么 fluent-bit 挂载时加 readOnly: true？
Fluent Bit 只需要读日志文件，不需要写。加 readOnly 是最小权限原则，防止 Fluent Bit 意外修改日志文件。
Logstash_Format On 是什么意思？
开启后 Fluent Bit 会按日期自动创建索引，格式为 {Logstash_Prefix}-{日期}，比如 nginx-logs-2026.03.11。这样每天的日志在不同索引里，方便按时间范围查询和清理旧数据。
DB /var/log/flb_nginx.db 是什么？
Fluent Bit 用这个 SQLite 数据库文件记录”读到文件的哪一行了”。如果 Fluent Bit 重启，它会从上次的位置继续读，不会重复发送已经处理过的日志。
1 | kubectl run curl-test --rm -it --restart=Never --image=curlimages/curl -- \ |
1 | kubectl port-forward -n es pod/easysearch-0 9200:9200 & |
返回结果：
1 | { |
Easysearch 自带了一个UI，但是跑在远程POD里，部署的Service也是Headless，所以没办法直接访问，我们的办法是先用kubectl port-forward把pod端口映射到服务器宿主机，然后再用 SSH 隧道把 9200 端口映射到本地：
1 | # 远程服务器上先跑 port-forward |
这样转发之后，我们也可以使用本机浏览器直接访问Easysearch自带的UI了。
Easysearch 最新版本要求密码至少包含 2 类字符，不满足时 Pod 直接崩溃（Exit Code 1），日志来不及写，非常难排查。
1 | # ❌ 纯小写 |
不设置的话 Easysearch 启动失败：
1 | sudo sysctl -w vm.max_map_count=262144 |
默认 JVM 堆 1G + 堆外内存，总共需要 2G+。小集群用：
1 | --set "javaOpts=-Xms256m -Xmx256m" |
我的自建集群没有默认 StorageClass 是 gp2，需要指定：
1 | --set storageClassName=gp2 |
如果环境自带 local-path-provisioner，不需要指定。
Fluent Bit 的 ini 格式不支持行内注释，# 后面的内容会被当成值的一部分：
1 | # ❌ 错误：行内注释会被当成值 |
1 | # Pod 状态 |
1 | # 删除 Nginx + Fluent Bit |
kubeadm 是 Kubernetes 官方提供的集群引导工具，用来快速创建符合最佳实践的 K8s 集群。除了初始化集群，它还能做节点的升级、降级等生命周期管理。用 kubeadm 建集群是学习 K8s 的推荐方式，也适合搭建小规模集群或作为更复杂企业级方案的基础组件。
本文基于 Ubuntu，使用三台 EC2 实例：一台作为控制面（Master），两台作为工作节点（Worker）。
我们会在 Master 节点上从头安装 kubeadm 及其依赖，然后初始化集群，最后把 Worker 节点加入进来。
这几台 EC2 使用同一个安全组，入站规则只放行VPC网段和终端访问地址。
以下操作在 Master 节点上执行（Worker 节点如果还没装也要跑一遍）。
kubelet 需要精确管理 Pod 的内存，swap 会让内存数据不准确，导致调度器做出错误判断。kubelet 默认检测到 swap 开着就拒绝启动。
1 | # 关闭 swap |
验证：free -h，Swap 行全是 0 就对了。
1 | ubuntu@ip-172-31-27-240:~$ free -h |
更新 apt 包索引，安装通过 HTTPS 访问软件仓库所需的包：
1 | sudo apt-get update |
加载 overlay 和 br_netfilter 两个内核模块。overlay 是 containerd 存储驱动需要的，br_netfilter 让 bridge 上的流量能经过 iptables 规则，K8s 的 Service 和 NetworkPolicy 都依赖这个。
1 | sudo modprobe overlay |
让 Linux 节点的 iptables 能正确处理桥接流量。三个参数缺一不可：
bridge-nf-call-iptables：bridge 流量过 iptables，Service 转发靠这个ip_forward：开启 IP 转发，Pod 跨节点通信需要bridge-nf-call-ip6tables：同上，IPv6 版本1 | cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf |
使用 Docker 官方分发的 DEB 包安装 containerd 作为容器运行时。这只是安装 containerd 的方式之一，也可以从源码编译或用其他包管理器。
1 | curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg |
生成 containerd 默认配置，然后把 cgroup 驱动改成 systemd。这一步是为了避免系统里同时存在两个 cgroup 管理器（systemd 和 cgroupfs）导致的不稳定问题。kubelet 默认用 systemd，containerd 也要对齐。
1 | sudo mkdir -p /etc/containerd |
从 Kubernetes 官方包仓库安装。三个组件的作用：
kubeadm：集群引导工具，负责 init 和 joinkubelet：每个节点上的代理，负责管理 Pod 和容器kubectl：命令行工具，用来操作集群下面以 v1.30 为例。如果要装其他版本（比如 v1.35），把两处 v1.30 都改成 v1.35 就行，GPG key 和源地址的版本号要一致。可用版本列表见 https://pkgs.k8s.io/core:/stable:/
1 | curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg |
K8s 组件版本需要严格对齐，自动升级可能导致版本不一致出问题：
1 | sudo apt-mark hold kubelet kubeadm kubectl |
以下操作仅在 Master 节点执行。
初始化过程会完成以下事情：
kubeadm 初始化使用合理的默认值，遵循最佳实践。当然也有很多配置选项可以自定义，比如使用自己的 CA 证书或外部 etcd 存储。
kubeadm 不会帮你安装网络插件，这个需要自己装。我们用 Calico 作为 Pod 网络插件。Calico 支持 Kubernetes NetworkPolicy，也是 AWS、Azure、GCP 的托管 K8s 服务内部使用的网络方案，生产可用。为了让 Calico 的网络策略正常工作，初始化时必须通过 --pod-network-cidr 指定 Pod 网络的 IP 范围。
1 | sudo kubeadm init --pod-network-cidr=192.168.0.0/16 |
192.168.0.0/16 是 Calico 的默认网段。注意这个网段不能跟你的 VPC 网络 CIDR 重叠，如果重叠了需要额外配置 Calico 来避免冲突。
输出会显示 kubeadm 初始化控制面的每一步。最后会给出两个重要信息：配置 kubectl 的命令和 worker 节点加入集群的 join 命令。
把输出最后的 kubeadm join ... 命令复制下来存好，后面 worker 节点加入集群要用。token 默认 24 小时过期，过期了可以用 kubeadm token create --print-join-command 重新生成。
用 kubeadm 生成的 admin kubeconfig 初始化 kubectl 配置：
1 | mkdir -p $HOME/.kube |
1 | kubectl get componentstatuses |
输出应该显示 scheduler、controller-manager、etcd 都是 Healthy。kubectl 能正常返回结果也说明 API Server 在正常工作。
1 | kubectl get nodes |
这时候控制面节点会显示 NotReady。这是正常的——因为还没装网络插件。
1 | NAME STATUS ROLES AGE VERSION |
可以用 kubectl describe nodes 看详细信息，Conditions 里会显示 Ready: False，原因是 “network plugin is not ready”，CNI（Container Network Interface）还没初始化。
Calico 有两种安装方式：Operator 和 Manifest。官方现在推荐 Operator 方式，通过 Tigera Operator 来管理 Calico 的生命周期，后续升级和配置变更都更方便。
先装 Tigera Operator：
1 | kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.0/manifests/tigera-operator.yaml |
再装 Calico 自定义资源：
1 | kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.0/manifests/custom-resources.yaml |
custom-resources.yaml 里默认的 Pod CIDR 是 192.168.0.0/16，跟 kubeadm init 时指定的一致。如果你用了不同的 CIDR，需要先下载这个文件改 cidr 字段再 apply。
这会创建一系列资源来支持 Pod 网络，包括：
Calico 组件会部署在 calico-system namespace 下（Operator 方式），而不是 kube-system（Manifest 方式）。
1 | watch kubectl get nodes |
1 |
|
网络插件初始化完成后，控制面节点会变成 Ready。可能需要等一分钟左右。按 Ctrl+C 停止 watch。
以下操作在 Worker 节点执行。
使用 kubeadm 添加工作节点比初始化控制面还要简单，一条 join 命令就搞定。
打开一个新终端，SSH 连接到 Worker 节点（用户名 ubuntu）。
用 sudo 加上之前从 kubeadm init 输出中保存的 join 命令：
1 | sudo kubeadm join 10.0.0.100:6443 \ |
如果 token 过期了（24 小时有效），在 Master 上重新生成：
1 | kubeadm token create --print-join-command |
回到控制面节点的终端，查看节点状态：
1 | kubectl get nodes |
Worker 节点会显示出来，ROLES 列为 <none>（这是正常的，worker 节点默认没有角色标签）。节点可能需要一分钟左右才能变成 Ready。
1 | kubectl get pods --all-namespaces |
所有 Pod 都应该处于 Running 状态。注意每个节点上都会有 Calico 的 Pod 在运行，负责该节点的网络功能。
1 | ubuntu@ip-172-31-27-240:~$ kubectl get pods --all-namespaces |
双节点集群到这里就搭建完成了。
集群搭好了，跑个 nginx 验证一下。
1 | kubectl run nginx --image=nginx --port=80 |
1 | kubectl get pods -o wide |
1 | ubuntu@ip-172-31-27-240:~$ kubectl get pods -o wide |
看 STATUS 是 Running，IP 已分配，记下 Pod 跑在哪个节点上。
1 | kubectl expose pod nginx --type=NodePort --port=80 |
输出里 PORT(S) 列会显示类似 80:31973/TCP，31973 就是 NodePort。
1 | # 用 Pod 所在节点的 IP + NodePort |
1 | ubuntu@ip-172-31-27-240:~$ curl 172.31.16.97:32686 |
能看到 nginx 欢迎页就说明集群网络正常。
注意：NodePort 通过节点 IP 访问，不是 ClusterIP。ClusterIP 是集群内部的虚拟 IP，只在集群内部可达。
在 AWS EC2 上用 Calico 默认的 BGP 路由模式，你可能会发现从一个节点直接 curl 另一个节点上的 Pod IP 不通。比如从 master（10.0.0.100）curl worker 上的 Pod（192.168.180.194）会超时。
路由表是对的（ip route | grep 192.168 能看到到 worker Pod 网段的路由），但包就是过不去。
原因是 AWS VPC 的源/目标检查（Source/Destination Check）。EC2 默认会检查每个网络包的源 IP 和目标 IP 是否属于这台实例，Pod IP（192.168.x.x）不属于 EC2 的 VPC 地址，VPC 直接把包丢了。
AWS Console → EC2 → 选中实例 → Actions → Networking → Change source/destination check → Stop
所有节点都要改。改完后跨节点的 Pod IP 直接访问就通了。
1 | ubuntu@ip-172-31-27-240:~$ curl 192.168.98.135 |
前面用 kubectl run 创建的是裸 Pod，不支持扩缩容。生产环境应该用 Deployment，支持副本管理和滚动更新。
1 | kubectl delete pod nginx |
1 | kubectl get deployment nginx |
10 个 Pod 会分布在不同节点上。
一行命令逐个 curl 所有 Pod IP：
1 | kubectl get pods -l app=nginx -o jsonpath='{range .items[*]}{.status.podIP}{"\n"}{end}' | while read ip; do echo "--- $ip ---"; curl --connect-timeout 3 -s $ip | head -1; done |
每个 IP 都输出 <!DOCTYPE html> 就说明都通了。
1 | # 缩到 3 个 |
k9s 是一个终端 UI 工具，比 kubectl 看集群状态直观很多，支持实时查看 Pod、日志、资源占用等。
Mac：
1 | brew install derailed/k9s/k9s |
Ubuntu/Linux：
1 | curl -sS https://webi.sh/k9s | sh |
或者直接下载二进制：
1 | curl -LO https://github.com/derailed/k9s/releases/latest/download/k9s_Linux_amd64.tar.gz |
装完敲 k9s 进入，按 : 输入资源类型（比如 pods、deploy、svc）切换视图从而看到集群的各种信息，q 退出。
*.github.io排查之后是source/CNAME 文件中配置了旧域名 airag.click
删除 CNAME 文件后重新部署就可以解决
1 | rm source/CNAME |
<username>.github.io 域名参考文档：https://docs.infinilabs.com/easysearch/main/docs/deployment/install-guide/helm/
首先添加helm仓库并更新。
1 | helm repo add infinilabs https://helm.infinilabs.com |
然后新建命名空间，我这里叫做es（下同），也可以使用其他名字。
1 | kubectl create namespace es |
Easysearch 依赖 cert-manager 来处理证书。使用这个命令来安装。
1 | kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.3/cert-manager.yaml |
否则就会收到如下报错。
1 | resource mapping not found for name: "easysearch-ca-issuer" namespace: "" from "STDIN": no matches for kind "Issuer" in version "cert-manager.io/v1" |
直接执行以下命令，我设置的命名空间固定是 es：
1 | cat << EOF | kubectl apply -n es -f - |
Easysearch Chart 默认开启了安全功能，需要在 es 命名空间下找到一个名为 easysearch-secrets 的 Secret，用来存放集群的初始化密码或通信密钥。
之前创建的是 easysearch-ca-secret（CA 证书），但系统还在找这个基础的 easysearch-secrets。
使用这个创建集群需要的secret：
1 | kubectl create secret generic easysearch-secrets -n es \ |
另外在启动集群之前，别忘记修改max_map_count：
1 | # 临时生效 |
都准备了好了之后我们来使用helm能够很方便的安装Easysearch：
1 | helm install easysearch infinilabs/easysearch -n es |
如果你的某个步骤有问题，修改配置之后需要重启，那么可以直接删除这个pod，然后K3S会自动按照当前配置拉起来一个最新的。
1 | kubectl delete pod easysearch-0 -n es |
在这个过程过，我发现helm里的Easysearch版本比较旧
不需要 uninstall，直接运行 upgrade。这样子就会触发 Kubernetes 的 **RollingUpdate (滚动更新)**：它会先停掉旧的 Pod，挂载原来的数据卷，然后启动 2.0.2 的新容器。
1 | # 使用 upgrade 命令，强行覆盖镜像 Tag |
然后可以使用helm继续安装console。
1 | helm install console infinilabs/console -n es |
我的集群开了http端口，可以进入pod进去call api。但是https没有反应。
1 | kubectl exec -it easysearch-0 -n es -- curl -u admin:easysearchpaswd http://127.0.0.1:9200 |
如果想清理数据或者重装，可以使用这些命令。
1 | # 卸载应用 |
那么在pod中我们怎么访问Easysearch呢？
我用busybox 当做例子，写了三种访问的方式
1 | kubectl run busybox-debug --rm -it --image=busybox -n es -- /bin/sh |
源码来自 cloudacademy/intro-to-k8s，用作学习笔记
1 | apiVersion: v1 |
这是最小化的 Pod 定义。只需要四个顶级字段：
apiVersion: v1 — 核心 API 版本kind: Pod — 资源类型metadata.name — Pod 名称，命名空间内唯一spec.containers — 至少一个容器，必须指定 name 和 image注意：使用 nginx:latest 时，Kubernetes 默认 imagePullPolicy: Always，每次启动都会拉取镜像。
1 | apiVersion: v1 |
相比 1.1 新增了 ports.containerPort: 80。如果不声明端口，kubectl describe 中端口显示为 none，外部无法知道容器监听哪个端口。声明端口是让 Kubernetes 知道容器对外提供服务的方式。
注意：即使声明了端口，从集群外部仍然无法直接访问 Pod IP（Pod IP 在容器网络内），需要通过 Service 暴露。
1 | apiVersion: v1 |
新增 labels.app: webserver。标签是键值对，用途：
selector 用来匹配目标 Podkubectl get 的 -l 选项用来过滤资源标签是 Kubernetes 中资源关联的核心机制。
1 | apiVersion: v1 |
新增 resources 字段：
requests：调度器据此选择节点，节点必须有足够的可分配资源limits：容器运行时的资源上限，超过内存限制会被 OOMKilled这里 requests = limits，QoS 等级为 Guaranteed（最不容易被驱逐）。不设置任何资源则为 BestEffort（最先被驱逐）。生产环境应始终设置资源请求。
1 | apiVersion: v1 |
selector.app: webserver — 匹配带有 app=webserver 标签的 Podports.port: 80 — Service 端口，对应 Pod 的 containerPorttype: NodePort — 在每个节点上分配一个端口（30000–32767），集群外部可通过 节点IP:NodePort 访问Service 解决的核心问题：Pod IP 不固定，Service 提供稳定入口并自动负载均衡。
1 | apiVersion: v1 |
命名空间用于隔离资源。不需要 spec，只需 name。使用 -n microservice 指定命名空间。
1 | apiVersion: v1 |
4 个容器在同一个 Pod 中，共享网络栈：
localhost:6379 连接 Redislocalhost:8080 连接 ServerimagePullPolicy: IfNotPresent 用于 latest 标签时防止每次都拉取。使用具体标签时默认就是 IfNotPresent。
局限性：Kubernetes 以 Pod 为最小扩缩单位，无法单独扩缩某个容器。如果需要独立扩缩，应拆分为多个 Pod + Service。
1 | apiVersion: v1 |
为服务发现课程创建独立的命名空间 service-discovery，隔离本课资源。后续所有命令需要加 -n service-discovery。
1 | # Service |
将 Redis 拆分为独立 Pod + ClusterIP Service。type: ClusterIP 是默认值，仅集群内部可访问。name: redis 为端口命名，后续可通过环境变量引用。
1 | apiVersion: v1 |
Kubernetes 自动为同命名空间的每个 Service 注入环境变量：
<SERVICE_NAME>_SERVICE_HOST → Service 的 ClusterIP<SERVICE_NAME>_SERVICE_PORT → Service 的端口<SERVICE_NAME>_SERVICE_PORT_<PORT_NAME> → 命名端口这里 DATA_TIER_SERVICE_HOST 和 DATA_TIER_SERVICE_PORT_REDIS 由 Kubernetes 自动注入，无需硬编码 IP。对比多容器 Pod 中的 redis://localhost:6379，现在通过 Service 跨 Pod 通信。
1 | apiVersion: v1 |
两种服务发现方式对比：
<service-name>.<namespace> 或同命名空间内直接用 <service-name>$(<SERVICE_NAME>_SERVICE_PORT) 等counter 用了完整 DNS（app-tier.service-discovery:8080），poller 省略了命名空间并混合使用了环境变量。DNS 方式更灵活，推荐使用。
1 | apiVersion: apps/v1 # Deployment 使用 apps API 组 |
从裸 Pod 升级为 Deployment：
replicas：期望的 Pod 副本数selector.matchLabels：Deployment 用来管理 Pod 的标签选择器template：Pod 模板，Deployment 据此创建和管理 Pod
1 | apiVersion: v1 |
与 4.3 相同的 Service + 环境变量服务发现，但 Pod 改为 Deployment 管理。
1 | apiVersion: apps/v1 |
与 4.4 相同的 DNS 服务发现，但 Pod 改为 Deployment 管理。注意支持层没有 Service（不需要被其他组件访问）。DNS 中的命名空间从 service-discovery 变成了 deployments。
官方提供了helm包，这使得我们可以很方便的下载OpenSearch的helm chart并且进行更新下载：
1 | helm repo add opensearch https://opensearch-project.github.io/helm-charts/ |
安装文档上来说，我们需要在value.yml里添加我们的密码，不过在我看来这不是一个比较优雅的做法，于是我采取了使用secret的方式来管理密码，这样可以把密码和Helm Chart进行解耦。先创建名为opensearch-admin-secret 的secret，然后指定密码：
1 | kubectl create secret generic opensearch-admin-secret \ |
然后再使用helm install安装opensearch，在这个时候把刚刚创建的secret传进去。
1 | helm install opensearch opensearch/opensearch \ |
由于我用的是亚马逊云科技的EKS，实际上还要处理关于CSI driver的问题。包括把gp2设置为默认的storageclass，以及使用 AmazonEBSCSIDriverPolicy这个策略，授权 EBS CSI Driver 操作 EBS 卷所需的 EC2 API 权限。
1 | kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' |
主要包括：
不过需要注意的是，通常来讲，在EKS上需要创建iam-oidc-provider 以及 iamserviceaccount来关联这个策略，以此来获得操作AWS API的权利。不过为了防止文章更加偏向于EKS，我修改了 hop limit，这是让EKS 的pod 可以像普通K8S一样访问host的资源。生产环境推荐使用 IRSA（IAM Roles for Service Accounts）通过 OIDC provider 关联 IAM 策略，这是 EKS 的最佳实践。本文为了简化流程，采用了修改 hop limit 的方式。
1 | # 获取每个node的 instance ID 然后修改 |
简单解释下：Pod 在容器网络里，经过 veth pair 到宿主机网络再到 IMDS，比实例本身多了一跳。所以 hop limit 为 1 时，Pod 里的 EBS CSI controller 无法访问 IMDS，拿不到 IAM 凭证，所有 AWS API 调用都失败。改成 2 就是允许多一跳，让 Pod 也能访问 IMDS。当然，如果你用的是其他K8S的发行版那么就可以跳过这个问题。
修改之后我们删除Helm Chart并且重建：
1 | helm uninstall opensearch |
如果需要更新，那么可以使用helm upgrade 来修改参数，helm默认启动了3个master节点，而我只有两个node，为了合理的分配一下资源，我决定对pod数量进行缩容。
1 | helm upgrade opensearch opensearch/opensearch \ |
这样我们多节点的OpenSearch Cluster就启动好了，当然服务在pod里，我们如果想本地测试（因为EKS控制平面是托管的，我无法登陆），所以使用kubectl port-forward来进行转发，这样就可以把端口代理到本地。
1 | kubectl port-forward svc/opensearch-cluster-master 9200:9200 & |
当然opensearch-dashboards也可以如法炮制进行安装：
1 | # helm 安装opensearch-dashboards |
然后通过浏览器打开 http://localhost:5601 登录，能够看到我们刚刚通过helm创建的两个Pod。
到这里，我们已经通过 Helm 在 Kubernetes 上成功部署了 OpenSearch 集群和 Dashboards。整个过程中我们用 Secret 解耦了密码管理，用 Helm upgrade 灵活调整了副本数。如果你想进一步探索，可以尝试配置 Ingress 暴露服务、接入 Fluent Bit 采集日志，或者通过 Index State Management 管理索引生命周期。希望这篇文章对你有帮助。
]]>在传统 Linux 下装 QEMU，你可能要折腾一堆 kvm-ok 检测、各种动态库依赖。但在懒猫微服上，直接从商店下载即可。这就是全容器化的好处：环境全封闭，不会把宿主机的依赖搞坏，不用再和底层依赖打交道，这就是懒猫微服全容器化的好处，彻底解决了让人头疼的环境问题。
和其他虚拟机一样，我们需要一个 ISO 镜像。QEMU 厉害的地方在于它对镜像来源几乎从不挑剔
可以直接填入官网的 ISO 下载链接，边下边装，省去中间转手的麻烦。
如果你的镜像在电脑里，或者在 NAS 上，那么可以直接在存放镜像的文件夹下打开终端，用一行 Python 命令把它变成“下载站”：
1 | # 进入镜像文件夹执行，默认开启 8000 端口 |
然后在 QEMU 的镜像地址里填入：http://你的电脑IP:8000/ubuntu-22.04.iso。
在懒猫微服的界面上，你只需要选好分给虚拟机的 CPU 核心数和内存大小。
如果你想稍微硬核一点，看看后台它是怎么运行的，其实 QEMU 常见的“加速”命令已经默默为你打好了。比如：
-m 2G：给虚拟机分配 2GB 内存。-smp 4：给虚拟机 4 核 CPU。当然你可以对这些参数进行修改，完成可以改成4C8G或者更高的配置。
当然也可以安装安卓系统，我尝试运行了BlissOS，很流畅，除了必要的X86和ARM指令集转换缺失之外，其他的都可以流程运行。甚至把虚拟机内部的 5555 端口（ADB 默认调试端口）通过端口映射的工具映射出来。这样，我们在局域网内的任何一台电脑上，只需要执行这个命令就可以进行ADB调试：
1 | adb connect 你的NAS的IP:你映射的端口号 |
进行端口转发之后，就可以像操作真机一样，直接用 adb install 往虚拟机里塞 APK，或者在线的调试。
安装完成之后，完全不用担心远程连接的问题，甚至还自带一个web的no-VNC。
好了，安装完了，咱们从纯技术的角度聊聊 QEMU，以及它和 KVM 到底是什么关系。
QEMU 是一个纯软件实现的虚拟机。它的强大之处在于“无所不拟”：它可以在 x86 架构（普通电脑）上模拟出 ARM、MIPS 甚至 PowerPC 的环境。
KVM（Kernel-based Virtual Machine）是 Linux 内核的一个模块。它的作用是让虚拟机直接调用 CPU 的硬件虚拟化指令（如 Intel VT-x）。
优点： 它的性能极快，几乎能发挥出硬件的真实水平。
局限： 但 KVM 很“高冷”，它只管 CPU 和内存，至于怎么模拟显卡、鼠标、USB 接口，它一概不管。
在懒猫微服里，我们默认用的是 QEMU-KVM 模式：
KVM 负责干体力活： 接管 CPU 和内存，保证运行速度飞快。
QEMU 负责干技术活： 模拟所有的外设（显卡、网卡、声卡、USB 驱动等），并提供管理功能。
总结：QEMU 是大脑和管家，KVM 是强壮的肌肉。两者是黄金搭档，才有了我们在懒猫微服上流畅的虚拟机体验。
]]>volume 和 bind 我就纠结了好久，以前习惯使用的是bind的方式。
1 | docker run -d \ |
然后… 起不来。
1 | docker logs easysearch-node1 |
日志里提示 JVM 配置文件找不到，服务启动失败返回 503。原因：宿主机的 ./node1/config 是空目录，Bind Mount 把它挂进去后，直接遮盖了容器内原有的 JVM 配置和默认配置文件。
老老实实按官方文档用 Named Volume：
1 | docker run -d \ |
Named Volume 挂载到容器内非空目录时，会自动把容器内的文件复制到卷里，包括 JVM 配置、默认配置等。集群顺利起来了：
1 | curl -ku admin:admin https://localhost:9201/_cat/nodes?v |
Easysearch 镜像内自带完整的默认配置：JVM 参数、节点配置、安全证书等。这些文件在容器的 /app/easysearch/config 目录里。
除非你用 init.sh 之类的脚本在宿主机预先生成了所有配置文件（包括 JVM 配置），否则不要用 Bind Mount 挂 config 目录。
| 特性 | Bind Mount | Named Volume |
|---|---|---|
| 容器内原有文件 | ❌ 被遮盖 | ✅ 空卷时自动复制 |
| 宿主机直接编辑 | ✅ | ❌ |
| 适合场景 | 宿主机已准备好文件 | 容器内自带默认配置 |
关键行为差异：
Bind Mount（Docker 官方文档）：
如果你把宿主机的文件或目录 bind mount 到容器内一个已有文件的目录，容器内原有的文件会被遮盖。
Volume（Docker 官方文档）：
如果你启动容器时创建了一个新卷，而容器内挂载目录（如 /app/）已有文件，Docker 会把这些文件复制到卷里。
Easysearch 这种容器内自带 JVM 配置和默认配置的场景，Named Volume 才是正确选择。Bind Mount 空目录会把这些文件全遮盖掉，别像我一样自作聪明。
周/日 计划
限制时间做事（30-90min） 紧迫感、
任务分解
短跑。起床坚持10分钟，其他事再坚持20分钟休息。 短跑30天习惯
日程校对，相信自己要做的事情。完全日程，避免过度工作和拖延。
自律。停下来之前再坚持10分钟。下次做事再坚持10-20%，专注一件事
语录刺激生产效率（便利贴
目标还是否能激励？有没有把生产力当作借口？
目标列出来看，承诺，便利贴看见
收集想法再整理剔除
尽可能的减少干扰
想要做/不去做。拒绝应该做。
先做收到反馈再调整
占据你时间但是价值的事情 根除或者压缩时间
事情条理性，定期维护
任务和物品整理好固定位置。（少混乱，少压力）
随时把想法记录下来（捕捉灵感
所有物品规定地方（和16差不读
GTD组织系统（项目-任务-活动）
项目：大类
任务：小的独立的行动。（总体待办/周目标/日目标）
活动：特定时间干的事（避免周日历太多）
写下目标，1. 不会遗忘。2. 有动力实现 3.模糊的想法变成具体目标
没有完美的系统就是设置分支，多文件夹 或者 决策的if else
通信记录承诺的事（日期时间 谁 内容 联系方式）
承诺的事整理起来不要忘记 设置时间线
有条理 减少检索时间
阅读笔记 - 提取关键信息
数字资料分类调理
晨礼（30-60分固定流程，锻炼，早晨应该避免过度脑力劳动，决定而第二天起床时间
每周给自己放一天假缓冲（上6休1） 剩下一天无所事事
有限的是精力不是时间，尝试早起20分钟慢跑
吃的少油少肉，多吃蔬菜和主食。少食多餐
吃掉那只青蛙。每天重要的事放在晨礼之后，每周重要的事放在周一周二
能量周期循环（休息-回复） 工作看成一系列短跑。每周一天放松不做生产力，每天晚上固定时间不想工作的事。
开环闭环理论，任务有明显的结束信号。
尽可能不要多进程处理，会让人变笨。
停止之前再坚持15分钟。
多喝水。杯子接满水。
回顾目标来充电。
换掉不能提供新想法的信息源。进行脑力训练。
工作 - 休息的循环。而不是放任自流。这只会变得懒惰。
不同的活动不同思维，累了就换一个。体能低就平衡创造力
完成项目不是任务，因为任务是动态的。
任务和项目的最后期限
每周90分钟回顾。独立思考，隔离其他的干扰源。
硬时间之前自己加一个软时间。（硬时间会积压一起）
帕金森定律：只要有时间，工作就会不断拓展，直到把时间用满。
霍夫施塔定律：在一件事情上花费的时间总是比想象中多得多。
生产力 不等于 工作。 简化复杂的项目，不做没有价值的大任务。断舍离用头脑挽救时间精力。
框架规划。只规划出来绝对必要的要素就可以了。不要过度规划，灵活决策后面做。
不要重复造轮子。用很少的钱换取别人几百个小时的劳动。
快速MVP迭代（找出版社之前先写一本电子书）
别按照时间会的报酬。（2-3小时干完，剩下时间休息
被逼出来的生产力（加任务/先休假）
每日检查标记
出口策略：完成工作之后做什么
起码目前阶段对我的M2 Macbook 兼容还不错，打算尝尝鲜。
没找到图形化安装或者ISO，只找到这个命令来做安装。
1 | curl https://alx.sh | sh |
纯CLI的安装方式其实没那么太友好，一开始显示还有200多G的空间但是
在终端中运行：
1 | tmutil listlocalsnapshots / |
方法 A（推荐）： 批量删除所有快照
1 | tmutil listlocalsnapshotdates | grep "-" | xargs -n1 sudo tmutil deletelocalsnapshots |
方法 B： 逐个删除（如果方法 A 无效）
1 | sudo tmutil deletelocalsnapshots 2024-01-15-123456 |
1 | tmutil listlocalsnapshots / |
应该显示为空或 “No local snapshots on this date”。
然后就是压缩MacOS磁盘给一个部分到这个Fedora，压缩磁盘的时候MacOS页面会卡死一阵子。
然后就是选容量和系统类型。剩下就是漫长的等待。
然后会把第一引导项改成Fedora。
剩下就是无脑跟着提示走，安全模式设置，然后就是初始化了。
嗯，Retina屏幕看啥都好看，在MacOS越做越烂的这些年，换个Linux玩玩吧。
]]>1 | adb shell pm list packages |
这里会列出很多app的包名，如果你知道叫啥名字页可以grep过滤一下。
然后，可以用这个命令看包名的地址。会给一个地址
1 | adb shell pm path <包名> |
然后使用adb pull这个地址，就可以在当前路径得到apk。
1 | adb pull <地址> |
最后发现根因是：磁盘剩余空间不足（< 5GB）触发 coco 自检阈值，直接 panic 退出，造成了“日志一直卡住、服务一直起不来”的假象，差不多排查了半个多小时。
目标是在 RK3566 / Armbian 上把 cocoai-arm:test 跑起来，并通过宿主机端口访问服务：
宿主机映射：-p 9000:9000
容器挂载 volume：
coco_data_vol:/app/easysearch/datacoco_config_vol:/app/easysearch/configcoco_logs_vol:/app/easysearch/logs一开始看到的现象是：docker logs -f 输出大量初始化日志
Easysearch 选主、集群状态、模板 / 索引迁移都能看到
但实际访问服务不通，或者看上去“卡在某一行不动”
Easysearch / ES 系产品常见依赖 vm.max_map_count，先按推荐值设置：
1 | sysctl -w vm.max_map_count=262144 |
确认 vm.max_map_count = 262144 已生效。
日志里还会看到一条：
1 | sysctl: setting key "net.ipv4.conf.all.promote_secondaries": Invalid argument |
这是系统 / 内核不支持该 sysctl 键导致的“噪音”，不影响 vm.max_map_count 是否生效。只要 grep 结果正确，就可以继续下一步。
这一步是整个排查的关键转折点：
不要只盯日志，要看容器里到底跑了哪些进程。
先看镜像入口：
1 | docker inspect --format 'Entrypoint={{json .Config.Entrypoint}} Cmd={{json .Config.Cmd}}' cocoai-arm:test |
输出类似：
["/sbin/tini","--","/sbin/entrypoint.sh"]["easysearch"]接着进容器看进程结构：
1 | docker exec -it cocoserver sh -lc 'ps -ef' |
可以看到非常关键的进程关系：
这一步直接改变了排查方向：
容器里不仅跑了 Easysearch，还跑了 supervisord，它负责拉起 coco。
所以“服务用不了”，问题很可能根本不在 Easysearch，而在 coco。
继续验证服务监听情况：
1 | docker exec -it cocoserver sh -lc \ |
容器里没有 ss，回退到 netstat，看到类似：
1 | tcp6 0 0 127.0.0.1:9200 :::* LISTEN - |
解读：
127.0.0.1:9200（loopback）127.0.0.1:9200 是没问题的把视角切到 coco 的 supervisor 日志（这是最关键的一步）：
1 | docker exec -it cocoserver sh -lc \ |
日志里可以看到两条定性信息：
1 | api server listen at: http://0.0.0.0:2900 |
以及真正的致命错误：
1 | [app.go:407] panic: disk free space [3.7G] < threshold [5G] |
到这里就完全对上了：
1）coco 确实尝试启动
2）启动后立即做磁盘空间自检
3）可用空间 3.7G < 5G 阈值
4）直接 panic 退出
5）日志不再输出，看起来像“卡住”
这次排查最后可以一句话总结为：
Easysearch 启动正常、集群 Green；真正导致 Coco Server 不可用的原因是：
coco 因为磁盘可用空间不足（< 5GB）触发保护阈值直接 panic 退出，造成“像卡住”的假象。
删除了一堆Docker images 释放了磁盘空间，Coco Server就能顺利启动了～
1 | # 1) 容器状态 |
我的手机上安装甲壳虫ADB一直闪退，所以使用无线ADB，开启之后效果大概这样子。
需要先打开开发者模式，然后在Mac上安装ADB。
1 | brew install android-platform-tools |
X300的ADB用的不是常用的5555端口，所以需要在这里找到配对码和配对端口（port1）。
大改就是先 adb pair 然后再 adb connect ，需要注意的是port1和port2是俩不同的端口。
Port1: 配对端口
Port2: 连接端口
1 | (base) ➜ ~ adb pair ip:port1 |
然后adb查看手机软件：
1 | adb -s ip:port shell pm list packages | grep terminal |
然后使用这个命令解锁终端，看到enabled之后就可以使用手机查看了。
1 | adb -s ip:port shell pm enable com.android.virtualization.terminal |
在手机里看操作系统信息，竟然是debian，不过看起来是纯内网使用。
可以调整磁盘大小。
还可以调整端口。
从这里看好像是一个没有不联网的Linux虚拟机，不过崩溃的频率还是有点高，有条件还是自己弄VPS尝鲜吧。
我的RK3566上是Armbian，但是没有配置网络环境，访问Dockerhub有问题，所以从Macbook 上下载玩，然后通过离线方式导成tar文件。我的镜像改了tag叫做cocoai-arm:test，你也可以不改。
1 | docker save -o cocoai-arm_test.tar cocoai-arm:test |
然后通过SCP上传到RK3566的开发板
1 | scp cocoai-arm_test.tar lckfb@192.168.5.36:~ |
补充：这个 warning 主要是 SSH 协商算法提示，不影响传输本身。真正要关注的是传输速度和是否中断——毕竟 900MB 级别的镜像，板子这边 IO 慢一点就容易“感觉很久”。
然后ssh到开发板上，使用docker laod命令还原这个Docker镜像。
1 | root@lckfb:/home/lckfb# docker load -i cocoai-arm_test.tar |
这个过程会花费一些时间，所以有时候假死直接等待就好了。漫长的时间过去之后，我们可以通过Docker images来查看镜像，还有一个Easysearch 镜像，是我之前测试的，也能够在嵌入式开发板上运行的很好。
1 | root@lckfb:/home/lckfb# docker images |
docker load “假死”一般是写盘/解包慢，我这个板子的 eMMC 速度就很一般。
顺手可以记一下：板子上镜像多了以后，存储空间会很快见底，后续最好固定一个清理策略（比如只留当前版本）。
然后使用这个命令启动，然后使用Docker PS查看。
1 | docker run -d --name cocoserver -p 9000:9000 \ |
图：容器已经跑起来，端口映射也生效。
我当时会顺手确认几个问题：
STATUS 是不是一直 Up，有没有出现反复重启（Restarting）？PORTS 是否显示 0.0.0.0:9000->9000/tcp（如果只绑到 127.0.0.1，局域网其他设备就访问不到）cocoserver 固定后，后续排查日志/重启都更方便：docker logs -f cocoserver
图：初始化日志在跑，说明服务在“慢慢起身”。
这张图我会重点盯两类信息：
error / exception / failed / oom / killeddocker stats 看 CPU/内存是否还有波动；也可以 docker logs --tail 200 cocoserver 快速看最近输出。漫长的等待之后，CPU很清闲，不过内存快用满了。
补充： 这种“CPU 很闲、内存紧张”的状态，在小板跑 Java/搜索组件/AI 服务时很常见，能跑起来不奇怪，关键是别被 OOM 一刀带走。
到这里，Coco AI Server 算是成功在 RK3566 上跑起来了：容器状态正常、日志能持续输出、端口映射也能对外提供访问。
]]>参考了这个方案：
兜兜转转回到了一个不折腾的方案：Win10 安装 Mobility Print Server → 发布本地打印机 → 手机走 AirPrint / Mobility Print 直接打印。
其实就是：
让 Win10 这台电脑充当“打印服务器”，把 USB/本地打印机发布到局域网里，手机就能像用无线打印机一样用它。
如果你家里有打印机可以试试，比CUPS的安装和运维成本小很多。
先把打印机的 Windows 驱动和配套软件装好（重点是：确保 Win10 上“本地打印”完全正常）。
有种折腾半生，安装Windows养老的感觉。
可以从这里看到了我安装的软件列表。Windows自带的打印机共享好像是SMB，总之是不太好用，我直接给他关掉了。
这个办法算是解决技术债，有条件还是建议买带无线打印的机器。
这里最容易翻车的是两件事：
1）Win10 睡死
很多人以为“屏幕熄灭”没关系，但如果机器进入睡眠/休眠，手机就会直接找不到打印机。
2）访客 Wi-Fi / 网络隔离
有些路由器默认把“访客网络”做了隔离，手机在访客 Wi-Fi 下是看不到你内网 Win10 电脑的——打印服务自然也发现不了。
让GPT写了一个命令，目测还挺稳的：让这台 Win10 在你需要打印时别睡过去（屏幕可以灭，但系统别休眠/睡眠）。
1 | powercfg -h off |
稍微解释一下这几行大概在干嘛（不用深究，但有助于排错）：
powercfg -h off：关掉休眠（顺带会禁用“快速启动”相关的一些行为）standby-timeout-* 0：不进入睡眠hibernate-timeout-* 0：不进入休眠monitor-timeout-* 10：屏幕 10 分钟后熄灭（省电，但不影响打印服务）在 Win10 上安装 Mobility Print Server（安装过程基本一路下一步即可），不需要额外安装组件
打开 Mobility Print Server 管理界面，在打印机列表里 勾选“发布/共享” 你的那台打印机，中间简单配置下用户名米啊么
Lenovo M7400 Pro（或者你自定义的队列名）给这台打印机设置一个共享显示名称
发布后，你会在界面里看到打印机处于可用状态，并且共享名称生效。
iPhone 这边基本是“傻瓜式”：
只要手机和 Win10 在同一网络里，你在任意支持打印的 App（备忘录、照片、文件）里点“打印”，就能看到你发布出来的打印机名称，选中即可打印。
也就是说：iPhone 端通常不需要额外装 App，体验非常接近原生 AirPrint。
安卓这边装一个 Mobility Print（App）就行。装好后同样确保在同一 Wi-Fi/同网段，然后在打印选择里找到你刚才设置的共享显示名称，直接打印。
如果你家里安卓机比较多，这个方案的好处是：一次配置，全家通用，后续基本就是“选打印机 → 打印”。
把 Win10 当打印服务器之后，手机端看到的体验就是：打印机像一台“真正的无线打印机”一样出现。
下面两张图就是我这边的实际效果（手机端能直接发现、直接选择、直接打印）：
用熟悉的Windows做Server，出问题还能RDP，有window原厂驱动还比CUPS少折腾了很多。也不需要买任何“无线打印盒子”，只要家里有一台 Win10 电脑能长期在线即可。
关键点就两个：
当然了，这个windows还能当远程小主机用，安装微信，Office远程办公也行啊。
其中AirPrint Installer对我没有起到什么明显的作用，只是可以在移动端搜到打印机了，但是每次都打印失败。
Bonjour 还留着了，也不确定是不是真的有用，现在能用就不折腾了。
但是默认的话，容器不会把这个 Easysearch 的端口映射出来，那就需要我们自己做些小的技巧：在官网的命令上修改一下，把 9200 端口先映射出来。
启动命令如下：
1 | docker run -d --name cocoserver \ |
启动之后，可以使用 netstat 看到容器端口的情况。换句话说，这个自带的 Easysearch 把 9200 和 9300 的端口确实启动起来了，但默认只绑定在 127.0.0.1 上，所以外部访问不到——即使你已经加了 -p 9200 也不行。
1 | docker exec -it cocoserver sh -lc "netstat -lnt | egrep ':9000|:9200|:9300' || true" |
1 | tcp6 0 0 127.0.0.1:9200 :::* LISTEN |
因为这部分是 easysearch.yml 控制的，所以我们可以直接通过命令更改，就使用 sed 替换吧。使用之前最好确认 Coco Server 进程已经起来了，防止不必要的问题。
1 | docker exec -it cocoserver bash -lc ' |
然后重启服务，就能通过 https://IP:9200 的方式访问 cocoserver 自带的 Easysearch 了。
1 | docker restart cocoserver |
这个时候我们再看端口的占用情况，已经开了外网访问（9200/9300 不再是 127.0.0.1，而是对外监听了）。
1 | (base) lzcbox-029c588e ~ # docker exec -it cocoserver sh -lc "netstat -lnt | egrep ':9000|:9200|:9300' || true" |
1 | tcp6 0 0 :::9300 :::* LISTEN |
Easysearch 的进程会先起来，Coco Sever 会慢一些。这时候可以通过 http://ip:9000 访问 Coco Server，也可以通过 https://IP:9200 访问 Easysearch 和 Easysearch 的 UI。密码还是老样子去 log 里找。
可以直接从 log 里把 curl 示例过滤出来，一般会直接告诉你默认账号密码：
1 | pg-docker logs cocoserver 2>&1 | egrep -i "curl" | tail -n 50 |
输出里会有类似这一行（账号通常是 admin，密码就是那串 Coco-Server-xxxx==）：
1 | curl -ku 'admin:Coco-Server-6dsxtGXhD+MUNhPBKf1hug==' https://localhost:9200 |
如果你是从宿主机访问，把 localhost 换成你的 IP 或 127.0.0.1 就行：
1 | curl -k -u 'admin:Coco-Server-6dsxtGXhD+MUNhPBKf1hug==' https://127.0.0.1:9200 |
然后我们就收获了一台可以在 Coco server 里使用的 Easysearch，可以实时查看数据。
平时用 API 写进去的数据还能被 Coco Server 索引，自带 UI 真的太爽了！
到这里就搞定了：Coco Server 自带的 Easysearch 不仅能正常跑起来，还能把 9200 端口暴露出来给外部访问。
日常用法也很简单：
那时候还不流行网络打印，但是现在看来确实是硬伤了。那我就计划把它改成“随时可用”。不求快，不求高级，只求你在任何设备上点一下就能打，别让我再拿着电脑跟着打印机跑。
大概前前后后摸索了这些方案：
我在第三个方法上进行了改良：不在OpenWrt上折腾了，换成用懒猫微服充当CUPS驱动传递的Server。
我这套里懒猫微服就干三件事：跑CUPS（带AirPrint）、挂网盘做中转、把Windows远程入口映射出去。
懒猫应用商店里直接可以下载CUPS服务端，内置了airprint协议，省去了自己折腾docker镜像的麻烦——别人测试好的我来开箱即用。
我们需要做的就是把USB直通给这个从商店下载的CUPS Docker。
这里有个很真实的小问题：每次打印机关机/重启、或者USB重新插拔以后，容器可能会读不到这个USB外设，所以每次都要重启一下容器来重新识别USB。
这个镜像内置了很多打印机驱动，所以我们选和打印机相同或者相近的型号的驱动。
我这里识别到了联想的打印机，可以直接添加：
填写信息，选择共享这个打印机。
列表里没有打印机的驱动，所以我选了兄弟的。（尽管测试下来兼容性有些问题，总之还能全平台凑合用）
打印机信息一览：
使用心得：
全平台的单页打印几乎都没什么问题，iPhone/iPad/Mac/Windows都能打，体验上就是“家里终于有一台网络打印机了”。
不过我的联想M7400 Pro在使用过程中遇到了两个很奇怪的问题，这是联想自己闭门搞驱动导致我使用的开源驱动无法适配导致的。
然后这一套方式也用了蛮久的。
如果你的打印机型号恰好在驱动列表里，那这套方案会非常舒服；你要做的就是商店装CUPS → 接打印机 → 选型号 → 结束。
如果型号不在列表里，那就像我这样：找个相近的驱动凑合用，能用到什么程度全凭缘分（以及厂商良心）。
我是一个爱折腾的人，前面的办法只适用于局域网打印，那么广域网怎么办呢？
再纠结了好久之后，我还是弄了一台Windows，一方面是给家里人使用，一旦出问题调试难度小一些，也顺便使用了联想的官方驱动，防止他再搞幺蛾子。
首先Windows通过客户端自动挂载SMB，这样就可以直接读到懒猫网盘的文件。
我对SMB挂载顺便改了名字。
大概打印流程是这样的：
收到文件 -> 传到懒猫网盘 -> 同步windows -> RDP登录WINDOW -> 直接打印
打开SMB之后，我们就可以看到从其他终端收到的文件。微信收到的文件也可以直接分享到懒猫网盘，这一步比“RDP里传文件”舒服太多了。
懒猫微服在这期间做了两件事：
我本来想给泰山派也刷一个：https://www.fnnas.com/download-arm 不过我看这里没有镜像了，估计是和OEC的关系影响到了RK3566的适配。
不用UTM的原因是大家都觉得很难用，所以还是选择了Parallel Desktop，安装很丝滑，几分钟就完成了。
自动识别到了飞牛的ISO，因为FN用的debian内核，就当debian用吧。（本质就是一套 Linux 安装流程，PD 对 Debian 这套适配也成熟，少踩坑。）
然后进入图形化安装流程，其实和安装debian一样的。
选择安装磁盘，这里是系统盘。
然后无脑安装就行了，等进度条。
安装进度条结束之后就看到了FNOS的标志，没有图形GUI。会显示IP地址。（这一步其实已经装完系统了，后续基本都在 Web 后台做初始化。）
然后从IP地址进入web后台，设置管理员用户名密码。
进入系统之后我们可以看到系统盘的容量，现在没有数据盘，所以没办法安装软件。（飞牛的应用基本都要落到存储空间里：没有数据盘=没建存储池=应用中心很多东西会直接灰掉。）
而且这个IP地址是虚拟机DHCP分的，我们需要改成和局域网一个网段。（不然每次重启 DHCP 变一下 IP，就得重新找；另外后面想从别的设备访问，也希望它像“局域网里的一台 NAS”，而不是“宿主机后面的一台小黑盒”。）
先停止虚拟机，我们做配置变更，加数据盘和改WIFI配置。
停机之后，加硬盘2。
网络配置也改成和宿主机共享无线网卡。（PD 这里如果走默认的 NAT，虚拟机通常在一个私有网段里，外面设备访问会绕一圈甚至直接不通；共享无线网卡等价于让虚拟机“挂”到当前 WiFi 这张网里，局域网可达性更好。）
修改完配置重启之后，我们会看到新的IP地址，然后进入后台之后，就可以看到新的数据盘了。
创建存储空间，我这里选Btrfs。（主要图它快照/校验这些特性，NAS 场景挺合适。）
就一块盘，存储模式也无所谓了。
接下来就是格式化。
等待存储池创建完成。
然后我们就可以从应用中心安装软件了。（有存储池之后，应用的安装路径、数据目录才有地方落盘。）
配置一览。
这套在 Mac 上用 PD 跑 FNOS 的方式，优点就是“快”和“稳”：几分钟起一台 NAS 环境，装应用、建存储池、跑基础功能都够用。等啥时候有时间，再慢慢折腾泰山派安装飞牛吧。
]]>
我买的：display link 是这个配置：
需要下载驱动Displaylink manager，然后系统里就能看到你在共享屏幕，
不管你在哪家买的硬件，应该用的都是这个软件。
Macbook Pro有三个Typec口，打算预留一个TypeC给其他设备，所以一开始用2个TypeC + 一个HDMI，而Display link也是实现的Typec转HDMI，所以整体的线就很乱。
1 | Macbook |
如果用Typec普通拓展坞接出来的HDMI是4K@30， 直接TypeC就是 4k@60。
突发奇想如果直接把USB接到显示器2上呢，好消息是能亮，还能4k@60，这不就是变相的菊花链～ MacOS不支持，但是Display link可以啊！！
虽然性能不如PCLE直连，不过CPU额外的算力对M芯片也不算啥，线都扔在后面了，桌面也比以前干净了。
]]>但是感慨的原因，并不在于某一个厂商被爆出漏洞，而在于我们一直默认家用 NAS 是一类“相对安全的设备”，但现实并不完全是这样。当我们做内网穿透、端口转发的时候，运营商会禁止我们对外提供服务，这么看来倒是一种保护了。在漫长的斗智斗勇过程中，我们也学到了不少专业知识，但如果非要用数据泄露来交学费，那实在是太过惨痛了。
先说清楚，这篇文章无意针对飞牛以及其他厂家，我也是飞牛，群晖和威联通的忠实用户。他们能在市场上有这么多用户量，靠的是真本事，这一点谁都没法否认。
但这次漏洞事件暴露出来的东西，不是换个品牌、打个补丁就能翻篇的。它让我开始琢磨一个更根本的问题：我们玩了这么多年的家用 NAS，这套远程访问的路子，是不是从架构上就有一道天花板在那摆着？
如果把情绪抽离掉，从工程视角来看，飞牛这次零日漏洞暴露出来的问题其实很清晰。攻击路径并不是“有人猜中了你的账号密码”，也不是“你没开双因素认证”。根据已公开的信息，这次事件中至少涉及一个 CVSS 评分 9.8 的严重目录遍历漏洞（CVE-2025-0510），攻击者无需任何认证即可从OS中获取敏感信息，执行任意脚本，完成从“数据窃取”到“完全控制”的整条攻击链。
从飞牛论坛用户的清理反馈来看，攻击者的持久化手段相当专业：修改系统启动脚本（system_startup.sh）植入恶意代码，加载恶意内核模块隐藏进程，给恶意文件设置 immutable 属性防止删除，甚至篡改 DNS 设置将 OTA 升级域名指向无效地址，让设备无法自动更新补丁。
有用户反馈恶意程序在凌晨三点定时激活，每隔一小时执行一次，反复清理三天才最终平息。飞牛官方虽然紧急发布了 fnOS 1.1.15 和 1.1.18 安全补丁，但对于那些已经被植入内核级后门的设备来说，补丁来得再快也已经晚了——因为攻击者早就把升级通道堵死了。
这不是飞牛独有的问题。SQL 注入是 OWASP Top 10 里最经典的漏洞类型之一，它出现在一个已经上市的 NAS 产品中，恰恰说明了一个残酷的现实：NAS 厂商的安全开发水平参差不齐，而用户对此几乎没有任何鉴别能力。放在任何一家做 NAS 的厂商身上，本质都是同一个模型下的必然风险。
我跟很多人的第一反应一样：后台开了 MFA，SSH 加了密钥认证，密码也够复杂，应该没事吧？
但这次事件让我不得不面对一个很残酷的事实：这些防护手段，防的是“有人试图登录你的账号”，而不是“有人绕过登录直接打穿你的服务”。零日漏洞的可怕之处恰恰在于，它往往发生在认证流程之外。攻击者不需要知道你的密码，不需要通过你的 MFA，他直接请求一个有漏洞的接口，就能拿到系统权限。你精心配置的那些安全措施，在这条攻击路径上根本没有出场的机会。
就像你给大门装了三道锁，但小偷是从窗户翻进来的。
这件事真正让我警醒的，是它逼我重新审视“家用 NAS 到底是什么”这个问题。我们习惯把 NAS 当成一个“带点智能的网盘”，买回来插上硬盘，装几个套件，配好远程访问，就觉得万事大吉了。
但从技术结构上看，它更像是一台长期在线的小服务器：有 Web 管理后台，有文件服务接口，有各种插件和后台服务在跑，有远程访问需求，有公网可达入口。换句话说，它具备了服务器的全部攻击面，却经常被用户用消费电子的心态来对待。我们会很自然地为了方便打开端口映射、配置 DDNS，让设备可以随时在外网访问，却很少有人真正意识到：这相当于把一台服务复杂、补丁节奏完全依赖厂商的服务器，直接放在了公网边缘，24 小时不间断地接受全球扫描器的“体检”。
飞牛的零日漏洞，其实只是把这个结构性问题放大到了所有人眼前。
我后来花了不少时间去想一个问题：为什么 NAS 的安全事故总是以这种方式发生？不是用户密码太弱，不是配置太离谱，而是厂商的某个服务组件出了洞，然后大量暴露在公网的设备被批量扫描、批量利用。
想来想去，答案其实很简单——因为传统 NAS 的远程访问模型，从根子上就是“让公网能直接打到你家设备”。无论你是通过端口映射、DDNS，还是厂商提供的云中转服务，最终都意味着你的管理面或服务面在公网有一个可被发现的入口。这个模型在便利性上没问题，但安全性完全依赖两个前提：厂商永远不出漏洞，以及用户永远配置正确。而这两个前提，在现实中从来没有同时成立过。
做过安全的人都知道一个很朴素的原则：缩小攻击面，永远优先于修补漏洞。与其指望“厂商永不出洞”，不如从架构上减少公网暴露。如果攻击者连你的设备都扫不到，那么即使系统里存在未知漏洞，被利用的概率也会断崖式下降。这不是什么高深的安全理论，这是安全工程的第一课。但遗憾的是，绝大多数消费级 NAS 的产品设计，并没有把这个原则放在优先位置。它们更关心的是“用户能不能方便地远程访问”，而不是“这种访问方式是否在架构上足够安全”。
也正因为这样，我后来开始反思一个更根本的问题：是不是我们一开始就选错了“家用私有云”的技术路线？传统 NAS 的远程访问模型，本质上是假设“公网直连 + 用户自行加固”，这在早期小规模使用时尚且可控，但随着 NAS 功能越来越复杂、用户群体越来越非技术化，这种模型注定会不断放大安全风险。它把服务器级别的安全责任，转嫁给了普通家庭用户，而这本身就是一个不太合理的设计前提。你不能一边把产品卖给“想要一个家庭网盘”的普通人，一边要求他们具备运维一台公网服务器的安全能力。
想清楚这一点之后，我重新选方案的第一标准就变了：不是功能多不多，不是品牌响不响，而是——公网能不能扫到我。在这个标准下，任何能做到“默认不暴露公网”的方案，都比传统 NAS 架构更符合我的安全预期。
后来接触到懒猫微服的时候，说实话我一开始是带着怀疑态度的。市面上打着“私有云”旗号的产品太多了，很多不过是换了个壳的 NAS。但真正让我停下来认真看的，是它的整体架构设计思路。
根据懒猫微服官方开发者文档的描述，懒猫微服的系统分为三层架构：最底层是一个极度精简的底层系统，只负责网络连接、安全认证，以及业务操作系统的启动和更新，目标是保证不管怎么升级，系统永远不会挂；中间层是业务操作系统，负责网络隔离、应用调度、资源管理；最上层是 LPK 应用层，这是懒猫自己的容器格式，官方强调这种容器格式在权限隔离与运行时控制上的安全边界更可控，并计划逐步补充网络流量审计、网络限制和用户权限控制等能力，用来尽量降低应用层对系统整体安全的影响。这种分层设计的好处很直观：底层保证稳定性，中间层保证隔离性，应用层尽量把风险限制在可控范围内，不会因为某一层出问题就牵连整个系统。
但真正让我觉得这个产品在安全思路上跟传统 NAS 拉开差距的，是它的网络传输机制。懒猫微服的远程访问分为两种模式：当终端设备所在网络具备 IPv6 或 NAT3 条件时，系统会自动与用户设备建立直连传输；当网络环境较差时，系统会自动切换到中继数据传输服务。关键在于，无论哪种模式，数据传输都采用端到端加密技术，传输内容对包括平台运营团队在内的任何第三方均不可见。而且这个穿透服务属于系统网络层能力，所有应用——包括官方应用、开发者自主开发的应用、甚至开发者搭建的虚拟机——都自动受益，不需要用户为每个服务单独配置网络穿透规则。
这意味着什么？意味着你不需要在路由器上开端口映射，不需要配置 DDNS，不需要自己搭建穿透机制或反向代理。设备是主动向外建立加密通道的，公网扫描器看到你家的公网 IP，也发现不了任何可直接访问的服务入口。这从根本上改变了攻击面模型：传统 NAS 是“我把服务摆在公网等你来连”，懒猫微服更像是“我主动出去建立连接，但外面的人看不到我”。对于这类零日漏洞的攻击场景——攻击者批量扫描公网 IP、发现暴露的管理接口、利用漏洞打进去——在这种架构下，第一步就很难成立，因为根本没有暴露在公网的入口可以被扫描到。
当然，这种“默认不暴露公网、依赖穿透与中继”的模型也不是没有代价：它对平台控制平面的稳定性依赖更强，也意味着用户在一定程度上需要信任厂商的网络基础设施能力。安全复杂度从用户侧转移到了平台侧，这对厂商自身的安全工程能力提出了更高要求。一旦平台侧出现故障，设备本身是安全的，但远程访问体验可能会受到影响，这是这种模型天然需要承担的代价。而且作为一个相对年轻的产品，它的生态成熟度跟老牌 NAS 厂商相比还有差距，自研的容器格式也需要更长时间的社区检验。这些都是选择这种架构路线之前必须接受的现实成本。
懒猫微服的理念文档里有一段话让我印象很深。它的创始人做了二十多年开源社区，他观察到的一个长期问题是：当个人数据逐步被公有云化之后，商业模式往往会不可避免地走向基于数据的变现逻辑。懒猫微服希望通过私有硬件把个人数据重新放回用户手里。这句话本身听起来像口号，但如果从产品架构反推，这确实是它很多设计选择背后的出发点——例如默认不暴露公网入口、强调端到端加密、尽量减少对第三方的信任假设。当一个产品从理念层面就把“数据尽量掌握在用户自己手里”当成优先目标，它在安全设计上的取舍，确实会和那些更偏向功能堆叠的产品不太一样。
从工程实现的角度看，懒猫微服更像是在家庭场景下尝试零信任网络的落地：默认不信任公网，默认不暴露服务，通过身份认证与加密通道来建立访问路径。它并不能保证系统永远没有漏洞——没有任何系统能做到这一点——但它把风险从“公网随意可达、被扫到就可能被打穿”，压缩到了“必须先突破身份体系和加密隧道”的范围内，攻击成本的量级明显不在一个级别上。
硬件层面的事情也值得单独提一下，因为很多人忽略了一个事实：安全能力本身是吃资源的。端到端加密、容器隔离、服务沙箱、AI 本地索引，这些能力全部打开之后，对 CPU 和内存的消耗是实打实存在的。很多入门级 NAS 为了控制成本，硬件资源本身就偏紧张，用户为了“用得顺”，最后只能关掉一部分功能，甚至包括一些安全相关的能力。懒猫的硬件定位更偏向“家庭私有云工作站”，整体资源相对充裕一些，所以在实践中更容易做到“该开的安全能力不需要为了性能被迫关闭”。这一点对安全体验的影响，其实比参数表本身更重要。
还有一点我觉得值得单独说的，是这个团队给人的感觉。
用过 NAS 的人大概都有过类似体验：遇到问题去官方论坛发帖，要么石沉大海，要么收到比较模板化的回复，很难确认对面是否真正理解你的具体场景。
懒猫这边给我的感受完全不一样。他们的一线技术支持是真正懂 Linux 的工程师在做，不是外包给念话术脚本的客服。你提一个问题，回你的人可能就是写那段代码的人，给出的不是套话，而是具体的排查思路或实现路径。用他们自己的话说，逻辑其实很简单：我们是最会玩 Linux 的那批人，你要的我们都有，花钱支持我们的客户，我们就实时响应。这种态度在国内硬件厂商里不多见，对我这种爱折腾的人来说，这种沟通方式本身就是产品体验的一部分。
实际使用下来也确实如此。懒猫有自己的用户论坛，也有比较活跃的社群，用户反馈的问题经常能看到开发团队跟进。社区里有一个长期存在的主题是“说出你的需求，我们来移植”，开发者会协助把用户常用的自托管应用移植到他们的应用体系里。官方还提供了一些社区激励机制，鼓励开发者参与生态建设。这些机制本身并不决定产品好坏，但它们让生态的扩展变成了一种可持续的系统行为，而不是完全依赖官方单点投入。
我在论坛上写了 80 多篇懒猫微服的实战连载，从开箱到进阶到炫技，写着写着就停不下来了。推荐你在论坛的攻略里感受到我折腾这台机器的状态：《懒猫智慧屏，我以为是地表最强电视盒子，结果竟然可以改装成闺蜜机？》《用懒猫微服倒推停电时间》《sunshine+moonlight 双人串流打游戏》《蓝牙音浪，懒猫开唱》《西湖邂逅后，我手把手教她玩转 NAS》《坏掉的 Windows 不要扔，硬盘插在懒猫上还能用》《服务器宕机之后，我和前端靠懒猫微服结对编程》。这些都是我在真实场景里折腾出来的记录。写着写着发现社区里其他人也在这么玩：有人用它存 Steam 游戏，有人用它替代 1Password 订阅，有人用它给大疆 Pocket3 导素材，有人用它做 24×7 在线开发机，有人用它的穿透服务让车机远程听黑群晖的歌。这些用法本身说明的不是“产品多强”，而是这种架构在家庭场景下确实覆盖了一些真实需求。如果你恰好是开发者，参与应用移植的过程本身也是学习——Docker 实践、npm 构建这些东西，社区里的工程师会直接带着你走一遍，至少在某个深夜，帮我解答了 docker 的 bind mount 和 volume 的异同和场景对比。
说回我自己现在的方案。折腾了这么一圈之后，我最终把家里的存储和服务迁到了懒猫微服上。不是因为它完美，而是因为它的安全模型让我第一次觉得“在远程访问这件事上不用操心”。不用开端口，不用配 DDNS，不用自己搭反向代理，也不用担心哪天又爆出一个新的零日漏洞就得手忙脚乱地去堵洞——因为公网本身看不到我的设备。端到端加密是默认开启的，平台侧也无法看到你的数据内容。三层系统架构把底层稳定性、业务隔离和应用安全分得比较清楚，不至于因为装了一个有问题的应用就牵连整个系统。
对我个人而言，权衡之后答案很明确：我宁可接受“平台偶尔不稳定”带来的体验波动，也不太愿意继续承担“设备 24 小时暴露在公网”这种结构性风险。前者更多是体验问题，后者本质上是安全问题，两者的风险量级并不在一个维度上。
如果一定要给这次零日漏洞事件一个更有价值的意义，那可能不是提醒我们“哪个厂商不安全”，而是提醒我们：家用 NAS 这条路，本身就存在一个被长期忽视的安全天花板。这个天花板不是靠换品牌能突破的，也不是靠多加几层认证能突破的，它是由“公网暴露”这个基本架构决定的。
这大概是这次事件教给我的最重要一课：安全这件事，靠补洞永远是被动的，靠架构才是主动的。选 NAS 不是在选品牌，而是在选默认风险模型。
]]>S3 (HTML模板) → Python脚本 → SES → 收件人
1 | #!/usr/bin/env python3 |
用 Langfuse 做 LLM 观测平台，拉 trace 数据时不小心把服务端打挂了。本文记录从发现 502 到定位 Node.js OOM，再到写脚本安全导出标注数据的完整过程。
Langfuse 是一个开源的 LLM 观测平台，用来追踪 LLM 应用的调用链路、记录 input/output、做人工标注评估等.
跑了一段时间，积累了不少 trace 数据和人工标注。某天想通过 API 批量拉取 trace 数据做分析，结果把服务端打挂了。
请求 /api/public/traces/{id} 接口拉取单个 trace 的完整数据时，先是返回 502 Bad Gateway，Nginx/OpenResty 报后端超时。
多请求几次之后，不只是 API 超时了，整个 Langfuse Web 界面都打不开了，彻底 503。
把容器日志扔给 AI 分析，定位到了问题：
1 | 大 trace 请求 |
exceeds 4MB）/api/public/traces/{id} 这个接口会返回 trace 的完整数据，包括所有 observations、spans、events 的全部 input/output。如果一个 trace 里有多轮 LLM 调用，每轮的 prompt 和 completion 都很长，那整个 trace 的 JSON 响应轻松超过 4MB。
Node.js 在序列化这么大的 JSON 时，内存占用会远超 JSON 本身的大小（因为要构建字符串、做 UTF-8 编码等），几个大 trace 同时处理就足以把 2GB 堆内存撑爆。
我的需求其实很简单：导出所有被人工标注为 “Good” 的 trace 的 input/output，用来做后续的微调数据集。
既然直接拉 trace 会把服务端打挂，那就绕开它：
| 接口 | 返回内容 | 风险 |
|---|---|---|
/api/public/traces/{id} | 完整 trace（所有 spans、events、input/output） | 响应体巨大，容易 OOM |
/api/public/observations | 按 traceId 查询 observations | 数据量可控，安全 |
/api/public/scores | 所有标注数据（不含 trace 内容） | 很轻量 |
策略：
/api/public/scores 拿到所有标注，过滤出 Good 的/api/public/observations?traceId=xxx 逐个拉取对应的 input/output1 | import requests |
/api/public/traces/{id}，改用 /api/public/observations?traceId=xxx，返回的数据量小得多get_with_retry 最多重试 3 次，每次间隔 3 秒，应对偶发的超时或 5xxsleep(0.5)，避免并发请求再次打挂服务端导出的 good_annotations.json 长这样：
1 | [ |
每条记录包含 trace ID、标注信息、以及对应的 LLM input/output，可以直接用来构建微调数据集。
/api/public/traces/{id} 接口会返回完整的 trace 数据，如果 trace 里有大量 LLM 调用，响应体很容易超过 4MB/api/public/observations 和 /api/public/scores 这类更轻量的接口，按需取数据--max-old-space-size 参数给 Node.js 扩大堆内存，或者在 Langfuse 前面加请求大小限制]]>相关链接：
- Langfuse 官网：https://langfuse.com
- Langfuse API 文档：https://api.reference.langfuse.com
我们今天就来聊聊第一个。NAS 似乎是给职业运维人员的福音，而广大的爱好者们通常都是野路子，靠着一腔孤勇或者是兴趣来维护自己的小小世界，能够借鉴参考的，也就是互联网的帖子以及各种群里的答疑而已。
靠着坚持不懈，入门了 Linux 和网络，但是不求甚解，安静的文件存储，只躺在方寸之间。
如果你恰好有一台懒猫微服，那么我们正好可以一起来学习这繁杂的网络，拆解这美丽的网络新世界。
我从事过几年的云行业，在发烧友和职业人员之间横跳，于是心有所感，立志让爱好者可以有专业的技术，让职业人员可以真的产生兴趣。这是网络篇。
首先你一定听说过 IP 地址，这是互联网通信的门牌号。我们的手机、电脑，包括懒猫微服都有一个 IP 地址。当你连上网络的时候，这个地址就被分配给了设备。准确地说，是分配给了网卡，所以懒猫微服可以用转接口来拓展第二张网卡。
连上网线之后，第一步我们习惯在路由器上看 IP 地址，然后 ping 一下确认连通。懒猫微服使用 IPv6，可以用 ping -6 或 ping6。
1 | ping 192.168.x.x |
我们也可以用 dig 查看域名解析的 IP 地址：
1 | dig +short xxx.heiyu.space # 因为是 IPv6，没有 IPv4 所以解析不到 |
在登录之前，可以用 telnet 看端口连通性，然后 SSH 上去。不过一般来说，直接 ssh root@域名/地址 就可以登录了。
1 | telnet xxx.heiyu.space 22 |
登录之后，我们可以使用 ifconfig 来看网卡信息。主要有这几张网卡比较有用：
或者使用 ip addr，会更加现代一点。
1 | lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 |
我们再来看一下路由表，使用 route -n 或者 ip route 来查看：
1 | Kernel IP routing table |
路由表决定了数据包往哪里走。
第一条 0.0.0.0/0 是默认路由，所有未知目的地的数据包都会被转发到网关 192.168.8.1（你的路由器）。路由器会通过 NAPT 来实现多台设备共用一个公网 IP 访问互联网。最后一条 192.168.8.0/24 是局域网直连，不需要经过网关。172.100.0.0/24 是 Docker 网桥。
NAPT（Network Address Port Translation）是 NAT 的一种，
也叫 PAT（Port Address Translation），它允许多个内部主机共享一个公网 IP 地址，
通过不同的端口号来区分不同的连接。
你家路由器做的其实是 NAPT：192.168.1.100:12345 → 公网IP:50001
192.168.1.101:12345 → 公网IP:50002
192.168.1.102:12345 → 公网IP:50003
如果你家里恰好有公网 IP，那么也可以通过在路由器上配置端口映射，将外部端口映射到内部的 IP 地址和端口上，让 NAS 可以被外网访问。
比如，你想让 NAS 的 SSH 服务（默认端口 22）可以从外网访问，可以在路由器上配置端口映射，将路由器的端口（比如 2222）映射到 NAS 的 IP 地址（比如 192.168.1.100）的 22 端口上。
不过懒猫微服自带了内网穿透，我们可以不用折腾这个部分了。
一般来说，家庭路由器的 IP 是 192.168.X.1，所以我们的机器可能是 192.168.X.2 或者其它地址。也就是说 192.168.X.0/24 就是我们局域网的网段。
192.168开头的是C类IP地址，后面/24表示子网掩码，也就是255.255.255.0
二进制表示就是 11111111.11111111.11111111.00000000也就是前24位是网络号，后8位是主机号。
一个子网内，主机号不能全为0或者全为1
192.168.1.0 网络地址（全0）
192.168.1.255 广播地址（全1）
192.168.1.1-192.168.1.254 可用地址
如果你的设备足够多，200 多个可能不太够用，那么就需要用更大的网段，比如 172.16.0.0/12，也就是 172.16.0.0 - 172.31.255.255 可用地址。
你也可能看到过 10 开头的地址，这是 A 类私有地址，范围更大：10.0.0.0 - 10.255.255.255。
好了，回到 DNS（Domain Name System）。它是互联网的核心服务之一，作为域名和 IP 地址相互映射的分布式数据库，让我们可以通过域名来访问网站，而不用记一串数字。由于懒猫做了转发，实际看到的不是真正的 IP 地址，这里我们快速略过。
在局域网内也可以用 dig 查看 IPv4 地址：
1 | dig +short your-lazycat.local |
这里看到的地址就和路由器上显示的一样了。
如果想要使用IPv6，那么你需要确保你的网络环境支持IPv6，并且你的路由器也支持IPv6。你可以通过以下命令来查看你的IPv6地址：
1 | ip addr show | grep inet6 |
因为 IPv4 地址已枯竭且存在 NAT 性能损耗，现代互联网依据 RFC 6724 国际标准和 Happy Eyeballs 算法，在操作系统和浏览器底层默认赋予了 IPv6 更高的连接优先级（Precedence），旨在确保连接更直接、高效的同时，通过给 IPv6 几十毫秒的“起跑优势”来实现全球网络向下一代协议的平滑过渡。
那我们如果想从微服的终端下载东西呢，有 curl 和 wget。通常来讲，curl 用来请求 API，比如测试接口，如果你的懒猫微服里发布了 API 可以用 curl 简单地测试；而 wget 主要用来下载文件。直接在微服上下载，比先下到电脑再 SFTP 传过去快多了。
1 | curl -X POST https://api.example.com/login \ |
1 | wget https://example.com/file.zip |
好了，接下来就是端口。
端口是一个逻辑概念，用于标识计算机上的不同服务。每个服务都会监听特定的端口，当有请求到达该端口时，系统会将请求转发给对应的服务。例如，HTTP 服务通常监听 80 端口，HTTPS 服务监听 443 端口，SSH 服务监听 22 端口。
在懒猫微服中，由于服务大多运行在容器中，所以似乎只有使用 pg-docker 的时候才会注意到端口，或者在终端里临时启动 web server：
1 | lzcbox-e66ccc4a ~ # python -m http.server |
那么我们如何知道哪些端口被占用呢？可以使用 netstat 或 ss 命令来查看。懒猫微服上容器多、服务杂，有时候端口冲突了，用这俩命令一查便知。我通常使用 -nltp：
参数解释：
-n 显示数字端口（不解析服务名）-l 只看监听状态-t 只看 TCP-p 显示进程信息1 | ss -nltp | grep 8000 |
1 | lzcbox-e66ccc4a ~ # ss -nltp | grep 8000 |
日常用
ss就行，更快。老系统或习惯了netstat也没问题，结果基本一样。
你可能也会看到其他人使用 lsof，同样可以查端口。lsof 除了查询端口之外，还能查询文件、进程等，这里不再赘述。
1 | apt update && apt install lsof |
知道端口被谁占了，下一步就是测试远程端口通不通。比如你在懒猫微服上起了个服务，想从电脑上确认能不能连上。
telnet 是最经典的方式：
1 | apt install telnet |
这就是 telnet 的用处——能看到服务返回的 banner 信息，做简单的服务识别。退出方式：按 Ctrl + ] 进入命令模式，然后输入 quit。
nc（netcat）更灵活，可以批量扫描端口：
1 | nc -zv 192.168.8.1 20-100 2>&1 | grep succeeded |
端口通了，但网络还是慢？那就要看看路径上哪一跳出了问题。比如你从懒猫微服访问外网资源很慢，想知道是家里路由器的问题还是运营商的问题。
1 | apt install mtr traceroute |
网络不通的时候，光 ping 只能告诉你”不通”，但不知道卡在哪一跳。这时候就需要 traceroute 或 mtr。
traceroute 是单次探测，跑一遍就结束：
1 | traceroute baidu.com |
mtr 更强，结合了 ping 和 traceroute，持续发包，实时显示每一跳的丢包率和延迟：
1 | mtr baidu.com |
网络时好时坏的时候，traceroute 可能刚好跑的时候没问题就抓不到，mtr 跑几分钟就能看到哪一跳在丢包。日常排查推荐用 mtr。
和 tcpdump 相比，tshark 的协议解析能力更强，能直接看到 HTTP 请求内容，而 tcpdump 只能看到十六进制。
懒猫微服上跑着各种服务，有时候想看看某个应用到底在发什么请求、收什么响应，tshark 就派上用场了。
懒猫的系统环境如果默认没装 tshark，需要使用这个命令进行安装
1 | apt update && apt install -y tshark |
用 tshark 抓一个本地 HTTP 请求，看看 TCP/HTTP 到底是怎么通信的。先在一个终端启动抓包：
1 | # 抓 lo 回环接口（本机访问本机走这里） |
然后另一个终端访问 curl localhost:8000，抓到 12 个包：
1 | tshark -i lo -f "port 8000" |
针对上图的结果，我也总结了一个流程图，请看：
1 | 客户端 (59548) 服务端 (8000) |
TCP 三次握手（建立连接）
1 | 1 59548 → 8000 [SYN] "我想连接你" |
为什么要三次？确保双方都能收发。两次不够——服务端不知道客户端能不能收到它的回复。
HTTP 请求/响应
1 | 4 GET / HTTP/1.1 客户端请求首页 |
TCP 四次挥手（关闭连接）
1 | 10 [FIN,ACK] 服务端 → 客户端 "我发完了" |
虽然抓包看只有三行，但逻辑上它们依然是四次挥手的变体。
一共 12 个包，一次完整的 HTTP 请求就完成了。
网络之道，说繁亦繁，说简亦简。繁在协议层层叠叠，简在万变不离其宗——包从哪来，到哪去。
能用 tshark 看懂三次握手，用 mtr 定位丢包，用 ss 追溯端口归属，便已胜过大多数人。
所谓高手，不过是在无数次折腾中，把书本上的知识化作了指尖的肌肉记忆。
而懒猫微服，恰是这样一方天地——自带穿透，容器隔离，root 权限在握，尽可放手施为。纵有闪失，重置便是，不伤筋骨。
这大概就是它最大的魅力：不只是一台 NAS，更是折腾 infra、钻研安全的瑞士军刀。
所有的好奇心，皆有安放之处。
]]>懒猫微服是分层文件系统，所以在之前的文章里前面我们使用用 systemctl --user 在开机时自动安装软件，解决重启丢包的问题。但说实话，每次开机都要跑一遍 apt install，当面对软件包过多以及网络延迟的问题的时候，使用dkpg会卡住，这不够优雅，所以才有了这个方案。
后来我换了个思路：既然懒猫微服天生就是为 Docker 而生的，为什么不直接用容器来跑这些工具呢？
想想看，htop、iotop、glances 这些运维神器，本质上就是读取 /proc 和 /sys 里的系统信息。只要让容器能访问宿主机的这些文件，不就能正常工作了吗？
这篇文章就来聊聊怎么用 Docker 容器跑系统监控工具。不用装软件，不怕重启丢失，一条命令就能用，用完自动清理。这让我们既享受了分层文件系统的优势，也不用再为软件持久化烦恼了。
关于镜像源：本文使用了
docker.1ms.run作为镜像加速站，仅作示例，不对镜像源的可用性负责。如果某个镜像拉取失败，可以换成其他镜像源，比如dockerpull.org、docker.xuanyuan.me等。
我们习惯的使用方式是 apt install htop，但在懒猫微服的分层文件系统下重启后会丢失。所以我们可以用Docker来一键设置：
1 | pg-docker run --rm -it --pid host docker.1ms.run/frapsoft/htop |
这条命令的作用是：启动一个包含 htop 工具的 Docker 容器，并以交互式方式查看宿主机的进程列表。容器停止后会自动删除。htop 是一个用于实时查看和管理系统进程的交互式工具。我们可以逐部分解析一下这条命令：
docker run:--rm:-it:-i 表示让容器保持交互模式（interactive），即允许你输入命令。-t 表示分配一个伪终端（tty），让你可以以终端方式与容器交互。--pid host:--pid host，容器可以查看宿主机的所有进程，这样你就可以通过 htop 查看宿主机的进程。frapsoft/htop:htop 工具的容器镜像。运行这个镜像会启动 htop，让你可以在容器中查看进程。为了方便，还可以在 .bashrc 里加个 alias，这样就能像本地命令一样直接敲 htop 使用了。
1 | echo "alias htop='pg-docker run --rm -it --pid host docker.1ms.run/frapsoft/htop'" >> ~/.bashrc |
在重启之后我们看到镜像没有丢失，还在本地存在，所以这个方式是可行的。
1 | lzcbox-e66ccc4a ~ # pg-docker images |
如果你经常玩docker，那么除了–pid之外一定都不陌生。对于默认来讲，–pid 的参数是 private，所以我们常说每个容器有独立的进程命名空间，容器只能看到自己内部的进程。用了**--pid host** 之后，容器就可以共享宿主机的进程命名空间。这样，容器可以查看宿主机上的所有进程，而不仅仅是容器内部的进程。所以我们可以用它来做一些监控。甚至还有，**--pid container:<container_id>**:- 容器将能够看到并与指定容器的进程共享命名空间。通常在多容器间需要共享进程信息或调试时使用。例如，一个容器需要查看另一个容器的进程或进行故障排查。当然我们这里不做仔细展开。
关于 Docker 参数解释以及 alias、bashrc 的修改，这里只以 htop 为例，后面的工具不再赘述。
同理我们也可以测试其他工具。
1 | pg-docker run --rm -it --pid host --net host \ |
glances 比 htop 更全面，是个「一屏看所有」的监控工具。CPU、内存、网络、磁盘、Docker 容器状态全都有。参数说明：
--pid host：读取宿主机进程信息--net host：读取宿主机网络信息-v docker.sock：让 glances 能监控 Docker 容器1 | pg-docker run --rm -it --pid host terorie/btop |
btop 界面更炫酷，功能也更丰富，支持鼠标操作。不过这个镜像比较冷门，docker.1ms.run 等加速站可能没缓存，所以这里直接用 Docker Hub 官方源。如果拉取慢，可以换成其他加速源试试。
1 | pg-docker run --rm -it \ |
这个镜像来自 quay.io（Red Hat 的镜像仓库），国内访问通常比 Docker Hub 顺畅，可以直接拉取。ctop 专门用来监控 Docker 容器的资源占用。
不过要注意，ctop 默认连接 /var/run/docker.sock，这是系统 Docker 的 socket。如果你想监控 playground 里的容器，需要挂载 playground 的 socket：
1 | pg-docker run --rm -it \ |
1 | pg-docker run --rm -it --net host --pid host --privileged docker.1ms.run/nicolaka/netshoot |
netshoot 内置了 tcpdump、iftop、nmap、curl、dig 等一堆网络工具，临时排查问题特别方便。网络监控工具必须加 --net host，否则测的是容器网络而不是宿主机网络。
进入容器后，先用 ip link 查看网卡名。懒猫微服的主网卡通常是 enp2s0 而不是 eth0：
1 | # 进入容器后 |
注意：netshoot 里没有 nethogs，如果需要按进程查看流量，可以用 alpine 临时安装：
1 | pg-docker run --rm -it --net host --pid host --privileged alpine sh -c "apk add --no-cache nethogs && nethogs" |
| 工具 | 特点 | 适用场景 |
|---|---|---|
| htop | 轻量、经典 | 快速查看进程，日常使用 |
| btop | 界面炫酷、支持鼠标 | 喜欢好看界面的用户 |
| glances | 功能全面、一屏显示所有 | 需要综合监控的场景 |
| ctop | 专注 Docker 容器 | 监控容器资源占用 |
| netshoot | 网络工具箱 | 网络排障、抓包分析 |
--pid host 的本质是让容器挂载宿主机的 /proc，而不是容器自己隔离的那份。
容器内的监控工具之所以能工作，是因为 Linux 的系统信息都存在 /proc 虚拟文件系统里：
| 文件 | 内容 |
|---|---|
/proc/cpuinfo | CPU 信息 |
/proc/meminfo | 内存信息 |
/proc/uptime | 运行时间 |
/proc/version | 内核版本 |
/proc/loadavg | 系统负载 |
/proc/<pid>/stat | 进程状态 |
常见工具的数据来源：
| 工具 | 读取的文件 |
|---|---|
| htop/top | /proc/<pid>/stat, /proc/meminfo, /proc/loadavg |
| free | /proc/meminfo |
| df | /proc/mounts, /proc/diskstats |
| ps | /proc/<pid>/status, /proc/<pid>/cmdline |
| netstat/ss | /proc/net/tcp, /proc/net/udp |
| vmstat | /proc/stat, /proc/vmstat |
| iostat | /proc/diskstats |
所以 --pid host 能让这些工具在容器里正常工作，因为它们本质上就是读文件，共享了 /proc 就等于共享了系统信息。
有个细节需要注意：/proc/version 和 /etc/os-release 记录的是不同层面的信息。
/proc/version 是内核信息，由内核动态生成：
1 | cat /proc/version |
/etc/os-release 是发行版信息，是静态文件：
1 | cat /etc/os-release |
打个比方：
/proc/version = 引擎型号（Linux 6.16）/etc/os-release = 车的品牌（Debian Linux）同一个内核可以跑不同发行版，所以如果你想让容器里的工具显示正确的操作系统名称，需要手动挂载 /etc/os-release。
我们经常习惯使用，fastfetch 显示系统信息，但还是没有找到别人打包好的容器的版本。fastfetch 是 neofetch 的现代替代品，速度更快。
我们可以用使用alpine安装二进制包的方式来运行，也可以自定义Docker images来跑：
先看一个使用alpine安装的：
1 | pg-docker run --rm -it \ |
参数说明：
--pid host：让 fastfetch 读到宿主机的 CPU、内存、内核信息-v /etc/os-release:/etc/os-release:ro：让 fastfetch 读到正确的操作系统名称-v /etc/hostname:/etc/hostname:ro：让 fastfetch 读到正确的主机名虽然不是很完美，但是已经可以读取到大多数的信息了，
再看一个自己打包的Docker版本。
1 | FROM alpine:latest |
构建并运行：
1 | pg-docker build -t my-fastfetch . |
同理我们也可以基于alpine构建基于任何软件的镜像工具，我这里再举一个例子，比如iotop。
1 | pg-docker run --rm -it --pid host --privileged docker.1ms.run/library/alpine sh -c "apk add --no-cache iotop && iotop -o" |
除了 /proc，Linux 还有 /sys 虚拟文件系统，存放硬件相关信息：
1 | # 读网卡 MAC 地址 |
除了 --pid host，Docker 还支持其他命名空间共享：
1 | # 共享网络命名空间 |
--pid container:<container_id> 在多容器调试时很有用，可以让一个容器看到另一个容器的进程。
你可能注意到有些命令用了 --privileged，这个参数会让容器获得几乎所有的宿主机权限：
/dev/*）/proc 和 /sys像 iotop、nethogs 这类需要深度访问内核信息的工具，没有 --privileged 可能跑不起来。但要注意，这个参数权限很大，只在信任的镜像上使用，用完记得 --rm 自动清理。
懒猫微服的分层文件系统固然好，但是常用软件会有丢失安装的问题，所以我们用容器来跑这些监控工具，容器镜像重启不会丢失，配置一个alias和bashrc就可以完美兼容这个feature。
容器里读取宿主机的参数有这三板斧：
--pid host--net host --privileged记住这三个，大多数监控工具都能在容器里跑起来。
回头看看，之前用 systemctl --user 开机自动装软件，虽然能用，但每次重启都要跑一遍 apt install，还会受限于软件体积和网络问题。现在换成 Docker 镜像，拉一次就永久缓存，重启秒开，彻底告别「开机等安装」的烦恼。
超越systemd，不用每次开机都再安装软件～
]]>在云计算时代，个人和小团队同样需要强大的计算能力、灵活的开发环境和丰富的应用生态。懒猫微服正是为此而生，它不仅能存储数据，更能像云服务器一样运行虚拟机、部署应用、搭建开发环境。从底层的虚拟化基础设施，到中间层的平台服务，再到上层的软件应用，懒猫微服构建了一个完整的私有云生态。
云计算的核心架构分为三层：IaaS（Infrastructure as a Service，基础设施即服务）提供虚拟化的计算、存储和网络资源；PaaS（Platform as a Service，平台即服务）在 IaaS 之上提供应用运行平台和开发工具；SaaS（Software as a Service，软件即服务）则提供开箱即用的应用软件。
用一个形象的比喻：IaaS 像是租了一块地和建筑材料，你要自己盖房子、装修、买家具；PaaS 像是租了一套毛坯房，你只需要装修和买家具；SaaS 则像是租了一套精装修的酒店房间，拎包入住。
懒猫微服正是基于这一架构理念，构建了完整的私有云计算平台。接下来，我们将深入探讨懒猫微服在这三个层面的技术实现。
让我们从最底层说起。IaaS 提供的是虚拟化的计算基础设施——虚拟机实例、块存储（Block Storage）、对象存储（Object Storage）、虚拟网络（VPC）、负载均衡器。这意味着什么？意味着你拥有了完整的基础设施控制权，但也需要承担相应的管理责任：操作系统、中间件、应用程序的安装配置，系统更新、安全补丁、网络策略的维护。AWS EC2、阿里云 ECS、Azure Virtual Machines 走的都是这条路。
懒猫微服在 IaaS 层做了什么？我们集成了 WebVirtCloud 虚拟化管理平台，让你可以轻松创建和管理各种操作系统的虚拟机。Windows 轻办公？没问题。各类 Linux 发行版（Ubuntu、Debian、CentOS、Arch Linux）做服务器？当然可以。想要 macOS 开发环境？甚至 Android 移动应用测试？统统支持。
更重要的是，我们在商店里内置了大量预配置的系统镜像。你不需要到处找 ISO 文件，不需要手动配置，就像安装手机 App 一样点击安装，虚拟机就跑起来了。这才是真正的开箱即用。
有意思的是，社区开发者还上传了群晖（Synology DSM）的虚拟机镜像。是的，你可以在懒猫微服里运行群晖系统——NAS 嵌套 NAS，这种玩法让你可以对比测试不同 NAS 系统的特性。
说到虚拟化，我们需要理解两种根本不同的架构。
Type 1 Hypervisor（裸金属虚拟化） 直接运行在物理硬件之上，Hypervisor 直接掌控硬件资源。这是性能、资源利用率、安全隔离性的最优解，也是企业级数据中心和云服务提供商的标准选择。VMware ESXi、Xen、KVM、Microsoft Hyper-V Server 都属于这一阵营。
Type 2 Hypervisor（寄居虚拟化） 则运行在宿主操作系统之上，作为应用程序层存在。安装配置简单，易于使用，这是它的优势。性能？确实略逊于 Type 1，但对个人用户和开发测试场景来说，易用性和灵活性更重要。VMware Workstation、Oracle VirtualBox、Parallels Desktop 走的是这条路。
那么懒猫微服选择了什么？ 我们采用 Type 2 架构，但不止于此。团队基于精简的 Linux 内核进行了大量性能调优，减少虚拟化层的开销，让性能表现接近 Type 1。这意味着什么？你既能获得高性能的虚拟化能力，又无需复杂的裸金属部署和配置。这才是真正适合个人和小团队的技术路线。
虚拟机很强大，但有时候你需要更轻量级的方案。这就是容器的价值所在。
懒猫微服基于 Docker 容器引擎，构建了三层容器管理架构。让我们逐层看看：
系统级 Docker（System-level Container Runtime） 运行着懒猫微服的核心系统组件和基础服务。这一层对你透明，系统自动管理，采用资源隔离和安全沙箱机制，确保核心服务的稳定性不受任何用户操作影响。
Playground Docker（开发测试环境） 这是你的实验场。支持 lzc-docker 和 Dockge 两种管理工具，你可以快速创建、销毁容器实例。想测试新版本数据库？想体验最新的开源项目？在 Playground 里随便折腾，完全隔离于生产环境，不会影响系统稳定性。
商店 Docker（容器商店） 这里的应用都经过我们工程师的专门审核，支持版本更新和一键部署。涵盖了你能想到的几乎所有中间件和应用：数据库服务（MySQL、PostgreSQL、MongoDB、Redis、Milvus 向量数据库）、搜索引擎（Elasticsearch、Meilisearch）、Web 服务器（Nginx、Apache、Caddy）、数据库管理工具（Adminer、phpMyAdmin、MongoDB Compass）、AI 大语言模型平台（Ollama、Ollama WebUI）、工作流自动化（n8n、Dify）。
虚拟机和容器，重量级隔离和轻量级部署，懒猫微服给了你完整的技术栈。虚拟机适合运行复杂应用和多租户场景，容器适合微服务架构和快速迭代。选择权在你手里。
技术应用场景： 独立开发者可以利用懒猫微服搭建 Kubernetes 集群学习环境。传统方案需要购买多台云服务器（每月数百元成本），而在懒猫微服上只需创建 3-5 个 Linux 虚拟机，部署 K8s 控制平面和工作节点，即可在本地环境进行容器编排学习和实验，零云服务成本。对于需要 macOS 开发环境但缺少 Mac 硬件的开发者，也可以通过虚拟化 macOS 系统进行应用开发和测试。
PaaS 在 IaaS 之上提供了更高层次的抽象，封装了应用运行所需的平台环境和开发工具。在 PaaS 层，用户无需关心操作系统补丁、运行时环境配置、负载均衡策略等底层细节，只需专注于应用代码开发和业务逻辑实现。PaaS 通常提供预配置的运行时环境（Node.js、Python、Java、Go 等）、托管数据库服务（自动备份、主从复制、故障转移）、CI/CD 流水线、API 网关、服务网格等能力。Heroku、Google App Engine、Azure App Service 是典型的 PaaS 产品。
懒猫微服在 PaaS 层构建了完整的平台服务体系，涵盖了应用托管、数据存储、服务治理等多个维度。
统一服务门户（Service Portal） 懒猫微服提供了平台级的服务管理能力，用于统一管理和访问 PaaS 层的各类技术服务（数据库、中间件、DevOps 工具等）。管理员可以通过服务门户进行服务配置、权限控制、资源监控等操作。此外，懒猫微服还支持静态网站托管服务，用户可以部署基于 HTML/CSS/JavaScript 的静态网站、单页应用（SPA）、技术文档站点等，无需配置 Web 服务器。
对象存储服务（Object Storage） 懒猫微服集成了 MinIO 和 RustFS 企业级对象存储系统，提供与 AWS S3 兼容的 API 接口。MinIO 支持分布式部署、数据冗余、版本控制、生命周期管理等企业级特性。用户可以通过 S3 SDK 或 MinIO Client 进行对象存储操作，适用于图片/视频存储、数据备份归档、大文件分发等场景。MinIO 的高性能架构可以充分利用本地存储的 I/O 能力，提供低延迟的数据访问。
数据库服务（Database as a Service） 懒猫微服提供了多种托管数据库服务，包括关系型数据库（MySQL、PostgreSQL）、NoSQL 数据库（MongoDB、Redis）、时序数据库（InfluxDB）等。这些数据库服务支持一键部署、自动备份、性能监控等功能，用户无需手动配置数据库参数和优化策略。
DevOps 工具链 懒猫微服集成了完整的 DevOps 工具栈，包括代码仓库（GitLab、Gitea）、CI/CD 平台（Jenkins、GitLab Runner）、制品仓库（Nexus、Harbor）。开发团队可以在懒猫微服上搭建完整的软件交付流水线，实现代码提交、自动构建、测试、部署的全流程自动化。
监控与可观测性（Observability Stack） 提供了 Prometheus + Grafana 监控方案、ELK（Elasticsearch + Logstash + Kibana）日志分析栈。用户可以根据需求实时监控系统资源使用情况、应用性能指标、业务数据趋势，快速定位和排查问题。
技术应用场景： 小型技术团队（3-5人）需要搭建开发基础设施。传统方案需要运维工程师花费数天时间采购服务器、安装操作系统、配置网络、部署各类中间件。而在懒猫微服上，技术负责人只需在应用商店中依次安装：GitLab（代码管理）、Jenkins（CI/CD）、PostgreSQL（业务数据库）、Redis（缓存）、Grafana（监控面板），配置导航页统一入口，整个过程可在 30 分钟内完成。团队成员通过导航页即可访问所有开发工具，大幅提升协作效率，节省了服务器采购和运维成本。
SaaS 是云计算的最上层，向最终用户提供开箱即用的应用软件。在 SaaS 模式下，软件的安装、配置、更新、备份、安全防护等工作全部由服务提供商负责，用户只需通过浏览器或客户端访问应用，专注于使用软件功能完成业务目标。SaaS 应用通常采用多租户架构（Multi-tenancy），支持按需订阅、弹性计费、数据隔离等特性。Gmail、Microsoft 365、Salesforce、Slack、Notion 都是典型的 SaaS 产品。
懒猫微服在 SaaS 层构建了丰富的应用生态，涵盖了个人生产力、协作办公、智能家居、安全管理、娱乐休闲等多个领域。
官方应用套件 懒猫微服提供了一系列官方开发的核心应用：懒猫网盘（基于 WebDAV 协议的私有云存储，支持跨平台同步）、相册管理（集成 AI 图像识别，支持人脸识别、场景分类、智能搜索）、Todo 清单（任务管理和 GTD 工作流）、智慧屏（信息聚合展示，支持自定义 Widget）。这些应用覆盖了个人用户的日常办公和生活需求，提供了完整的数据主权和隐私保护。
导航页应用生态 在 SaaS 层，懒猫微服支持多种导航页应用，用户可以根据个人喜好选择和配置。这些导航页应用需要用户自行安装和配置，用于管理个人书签、快速访问常用网站和服务。包括 LazyCat 导航（官方导航页）、HomeNexus 导航（现代化服务导航面板）、T-Nav 导航网站（轻量级导航工具）、Van-nav（轻量级导航站）、Nav8（现代化个人导航页）、Sun-Panel（NAS 导航面板）、BookNav（基于 Flask 的书签导航）、Flare（个人导航、快速、美观的个人导航页）、Catsite（美观实用的个人导航）、Easy Gate（开箱即用的导航管理）、homepage（高度可定制的导航页）等。每个导航页应用都有不同的设计风格和功能特点，用户可以根据自己的审美和使用习惯进行选择和定制。
智能家居与自动化 懒猫微服支持 Home Assistant（开源智能家居平台，支持数千种智能设备接入，提供自动化场景编排、设备联动、语音控制等功能）。用户可以在懒猫微服上搭建完整的智能家居中枢，实现本地化的设备控制和数据隐私保护，无需依赖云服务商。
安全与隐私工具 集成了 Bitwarden（开源密码管理器，支持端到端加密、多设备同步、密码生成、安全审计等功能）。用户可以在懒猫微服上自建密码管理服务，完全掌控敏感凭证数据，避免第三方密码管理服务的潜在风险。
社区开发者生态 懒猫微服拥有活跃的开发者社区，第三方开发者贡献了大量高质量应用。音乐播放器（支持本地音乐库管理和流媒体播放）、Rustdesk 远程桌面服务端（开源的 TeamViewer 替代方案，提供端到端加密的远程访问）、微信排版工具（Markdown 编辑器，支持微信公众号格式导出）、Office 办公套件（基于 OnlyOffice 或 Collabora Online 的在线文档编辑）等应用，极大扩展了懒猫微服的应用场景。
游戏娱乐平台 懒猫微服还支持游戏应用的部署。包括 Web 小游戏、PSP 模拟器、甚至移植的 3A 游戏大作。用户可以在懒猫微服上构建个人游戏库，通过流式传输技术在不同设备上游玩。
技术应用场景： 摄影爱好者拥有数万张照片（总容量超过 500GB），需要一个私密且便捷的管理方案。使用公有云存储服务（如 iCloud、Google Photos）面临隐私风险和持续订阅成本。在懒猫微服上部署懒猫网盘和相册应用后，可以实现照片的自动备份（通过移动端 App 或 WebDAV 协议）、AI 智能分类（人脸识别、场景标签）、全文搜索、跨设备访问。数据完全存储在本地，无隐私泄露风险，也无需支付月度订阅费用。家庭成员可以通过权限管理共享相册，实现家庭照片的集中管理和协作浏览。
懒猫微服不仅仅是一个 NAS 存储设备，更是一个完整的云计算平台。它打破了云计算只属于大企业的刻板印象，让个人用户、独立开发者、小团队也能拥有媲美云服务商的基础设施能力。
从底层的虚拟化基础设施（IaaS），到中间层的平台服务（PaaS），再到上层的软件应用（SaaS），懒猫微服为用户提供了全栈的云计算解决方案。你不需要每月支付高昂的云服务费用，不需要担心数据隐私泄露，不需要受限于云服务商的各种限制。一台懒猫微服，就是你的私有云数据中心。
无论你是想搭建个人博客、学习新技术、开发应用、管理家庭数据，还是为小团队提供开发环境，懒猫微服都能满足你的需求。云计算不再遥不可及，它就在你的桌面上，触手可及。
这就是懒猫微服的愿景：让每个人都能拥有自己的云计算平台，让技术真正为生活和工作赋能。
]]>主要好处：
下载速度快，节省带宽和磁盘空间
适合只想获取最新代码、不关心历史记录的场景
比如一个有几千次提交的大仓库，完整克隆可能要几百 MB，用 –depth 1 可能只需要几十 MB。
常见用法：
git clone –depth 1 https://github.com/user/repo.git
git clone –depth 10 https://github.com/user/repo.git
缺点是你看不到完整的 commit 历史，也没法切换到旧的分支或标签。如果后续需要完整历史，可以用 git fetch –unshallow 补全。
match 和 term 傻傻分不清？聚合查询写半天还报错？今天教你用 MCP（Model Context Protocol）封装 Easysearch，让 AI 帮你操作集群。从此告别 DSL，用自然语言就能完成搜索、写入、聚合统计！
先看看最终效果。以下是我和 Kiro 的真实对话记录：
我：集群健康吗？
Kiro：
1 | { |
🟢 集群很健康！状态 green，1 个节点，2 个活跃分片，100% 健康。
我：创建一个产品索引，有名称、价格、分类、描述字段
Kiro：
1 | { |
产品索引创建成功！字段结构：
| 字段 | 类型 | 说明 |
|---|---|---|
| name | text | 产品名称，支持中文分词搜索 |
| price | integer | 价格 |
| category | keyword | 分类，精确匹配 |
| description | text | 描述，支持中文分词搜索 |
我：写入 5 个苹果产品
Kiro：
1 | { |
5 个产品写入成功！
我：搜一下带芯片的产品
Kiro：
1 | { |
找到 3 个带芯片的产品！
我：5000 以下的有哪些？
Kiro：
1 | { |
5000 以下有 2 个：AirPods Pro 2（¥1899）和 iPad Air（¥4799）
我：按分类统计数量
Kiro：
1 | { |
我：平均价格多少？
Kiro：
1 | {"value": 7839.0} |
平均价格 ¥7839
全程不用写一行 DSL！我只说人话，Kiro 自动选择合适的工具、生成查询、返回结果。
MCP（Model Context Protocol）是一个让 AI 调用外部工具的协议。简单说：
把 Easysearch 的操作封装成 MCP 工具，AI 就能帮你操作集群了。
FastMCP 是 MCP 官方提供的 Python 高级封装，让你用最少的代码写 MCP Server。
1 | from mcp.server.fastmcp import FastMCP |
FastMCP 的优势：
@mcp.tool() 一行搞定工具注册1 | easysearch-mcp-server/ |
1 | pip install mcp httpx |
创建 easysearch_mcp.py：
1 | """ |
1 |
|
1 |
|
1 |
|
这是最有价值的部分，让 AI 帮你写 DSL：
1 |
|
1 |
|
1 | if __name__ == "__main__": |
在项目根目录创建 .kiro/settings/mcp.json：
1 | { |
配置说明：
command: Python 解释器路径，建议用绝对路径如 /usr/bin/python3args: MCP 服务器脚本的绝对路径env: 环境变量，配置 Easysearch 连接信息autoApprove: 自动批准的工具列表。默认情况下 Kiro 调用 MCP 工具前会弹窗让你确认，把工具名加到这个列表里就会自动执行，不用每次点确认，对话更流畅重新加载 MCP：Cmd+Shift+P → 搜索 “Reconnect MCP Servers” 执行即可。
连接成功后，在 Kiro 左侧面板的 “MCP Servers” 视图里可以看到 easysearch 显示为绿色。
继续看几个实际操作：
我：有哪些索引？
Kiro：（调用 list_indices）
1 | { |
目前有 1 个索引 products，包含 5 个文档。
我：products 索引有什么字段？
Kiro：（调用 get_index_mapping）
1 | { |
products 索引有 4 个字段：name、price、category、description。
我：集群有多少文档？
Kiro：（调用 cluster_stats）
1 | { |
集群共有 3 个索引，13 个文档，存储大小约 52KB。
我：写入单个文档
Kiro：（调用 index_document）
1 | { |
我：查一下 ID 是 magsafe-001 的文档
Kiro：（调用 get_document）
1 | { |
我：搜一下手机分类的产品
Kiro：（调用 search，生成 term 查询）
1 | { |
我：价格最高的是哪个？
Kiro：（调用 aggregate，agg_type=max）
1 | {"value": 16999.0} |
最高价格是 ¥16999（MacBook Pro 14）
我：价格最低呢？
Kiro：（调用 aggregate，agg_type=min）
1 | {"value": 1899.0} |
最低价格是 ¥1899（AirPods Pro 2）
我：算一下总价
Kiro：（调用 aggregate，agg_type=sum）
1 | {"value": 39195.0} |
5 个产品总价 ¥39195
我：删掉这个文档
Kiro：（调用 delete_document）
1 | { |
我：删掉 products 索引
Kiro：（调用 delete_index）
1 | {"acknowledged": true} |
索引已删除！
封装完成后，AI 可以使用这 12 个工具：
| 工具 | 功能 | 典型用法 |
|---|---|---|
cluster_health | 集群健康状态 | “集群状态怎么样” |
cluster_stats | 集群统计 | “有多少文档” |
list_indices | 列出索引 | “有哪些索引” |
get_index_mapping | 查看字段结构 | “products 索引有什么字段” |
create_index | 创建索引 | “创建一个用户索引” |
delete_index | 删除索引 | “删掉 test 索引” |
index_document | 写入文档 | “添加一个产品” |
get_document | 获取文档 | “查一下 ID 是 xxx 的文档” |
delete_document | 删除文档 | “删掉这个文档” |
bulk_index | 批量写入 | “导入这批数据” |
search | DSL 搜索 | “价格 1000-5000 的产品” |
search_simple | 关键词搜索 | “搜一下 iPhone” |
aggregate | 聚合统计 | “按分类统计” |
AI 根据工具描述选择调用哪个，描述写得好，AI 选得准：
1 |
|
Easysearch 原始返回包含大量元数据，动辄几百行。直接返回给 AI 会占用太多 token，也会干扰理解。精简后只保留关键信息：
1 | return { |
search 需要写 DSL，search_simple 只要关键词。AI 会根据场景选择：
search_simplesearch 生成 range 查询这个 MCP 还可以继续扩展：
通过 MCP 封装 Easysearch：
完整代码已开源，拿去用吧！
.kiro/settings/mcp.json：
1 | { |
easysearch_mcp.py：
1 | """ |
新电子产品的第一年都很稳，各种满核心编译Java都没有问题。不知道是系统更新还是厂家为了迭代产品，基本都是快过保的时候出问题。
去年冬天突然遇到死机黑屏问题，Typora文档写一半黑屏了，长按电源键无法开机，来回折腾要半个小时以上。去天才吧维修，说硬件测试没问题（其实就是快捷键）， 千篇一律的官僚主义（记住这个词后面要考）拒绝返厂，然后拒绝我的各种专业建议，给我的建议就是备份重装，但是，崩溃依然继续。 于是求助群友，我竟然不是个例。
半年后，继续找他们掰扯，理由是过了一段时间无法证明我说的重装系统不能复现问题。给的方案还是重装。继续拒绝返厂检测。
期间也陆陆续续和线上沟通，在这期间对这个品牌的售后彻底失望。行政关系团队的陈先生，带着一种高高在上的口吻来“解决问题”。关于我反馈他们的专员一问三不知，完全有失一个技术人应有的技术储备的时候。他轻描淡写谈写，“我不是技术方向的，所以我不对技术层面的事情做评价，我们的专员是经过专业培训的，所以你要相信他们”。然后他们向上反馈，客户不配合，无法继续排查问题，服务被迫终止。留下一句，你要去网上发帖子是你的权利云云。仿佛这一切就是他们的日常。
收集了日志，和我说是电脑plist文件格式有问题，于是反问哪个软件的？这个你们xcode为什么不校验？对方摆烂。让我做删除某某目录的操作，问这个操作是做什么的，删除有什么后果，对方语塞。还好有备份，这个操作会直接导致系统里的ruby无法使用，而MacOS的一些组件还是依赖这个的。
不管是电话里还是天才吧，要录音留影的时候，对方理直气壮的拒绝服务，是真的不敢么。
所以啊，当致电400的时候，apple电话里的“请礼貌对待他们”，有没有可能真的是你们的问题呢？
如果国产OS做的好一点，不那么好大喜功，可能国产真的很符合国人的使用习惯，赶超欧美也只是时间的问题。
于是心得：如果去找Apple线上的客服问问题，可能还没有自己查文档来的快。
这已经不是，某天才吧店，听着所谓的专员对着客户说，“IOS之所以能成为一个独特的操作系统，原因….” 小伙伴说他是伪科普，我说现在已经不是10年前了。所谓apple专员的话术在当年可能觉得专业，现在只是一种甩锅的手段罢了。
言归正传，说到Macbook的崩溃，随着时间关系，已经从写写文档直接黑屏无法启动变成了睡眠直接睡死，然后变成了做一些文字工作鼠标卡死，SWAP爆满。虽然我的使用习惯不是特别好，但是这些年的黑苹果，从来没出现过这些问题，所以对Macbook 抱有希望，全家桶是果黑的第一步，没错。苹果生态很好，但不是唯一。
一次偶然的机会，了解到kernel task。默认的任务管理器是不显示的，也就是我们看系统监控的时候，看到的占用总是和实际不符。
1 | 活动监视器 - 显示 - 所有进程，分层显示。 |
关于kernel task，有说左边插显示器会导致温度异常的，有说系统过热保护的。但，只有跑大模型的时候风扇才会拉起来，但是这不等于机身不烫。通常来说，电脑卡的时候，kernel task的CPU占用率通常拉到100%，极端的时候我的CPU可以拉到接近500。
说句玩笑话，因为系统的自我保护，包括但不限于温度过高，负载过重等等，这个保护进程会占用大量的CPU和内存资源。从而导致系统卡顿，打字延迟，开会音频撕裂。在那些年的黑苹果生涯，我从未遇到过。
kernel task这个进程，不能被kill。所以最后的方案就是重启电脑，以及在下次打开的时候要至少停止30秒，或者什么也不干，让CPU当下此刻满载让kernel task充分发挥威力，一直到CPU降下来。
也许我并不怀念那个需要熬夜改驱动的时代，我怀念的是那个技术至上、凡事求真求实的江湖。
当一家顶尖科技公司的售后开始用“我不懂技术”当挡箭牌，用“相信培训”来掩盖逻辑缺失时，对于拥有专业技能的发烧友来讲，这是不止是傲慢，更是对技术本身的亵渎与放逐。
折腾了十年，我躲过了黑苹果遍地的驱动坑，却终究没躲过白苹果这堵官僚墙。
]]>本文将带您从零开始，在本地搭建 AgentCore 开发环境，并通过详细的代码解析，帮助您深入理解每一个技术细节。
Amazon Bedrock AgentCore 是一套专为 AI Agent 设计的企业级基础设施服务。它解决了 Agent 从原型到生产过程中的核心挑战：
本地开发的优势在于：开发者可以在熟悉的环境中快速验证想法，无需等待云端部署，同时保持与生产环境一致的代码结构。
我们推荐使用 uv 作为 Python 包管理器，它具有更快的依赖解析速度和更可靠的环境隔离能力。
macOS 和 Linux 系统：
1 | curl -LsSf https://astral.sh/uv/install.sh | sh |
Windows 系统：
1 | powershell -c "irm https://astral.sh/uv/install.ps1 | iex" |
安装完成后，请重新打开终端以使环境变量生效。
AgentCore 需要访问 Amazon Bedrock 服务，因此需要配置有效的 AWS 凭证。
1 | # 验证当前凭证配置 |
如果尚未配置凭证，请执行：
1 | aws configure |
系统会提示您输入 Access Key ID、Secret Access Key、默认区域和输出格式。
在 AWS 控制台中，导航至 Amazon Bedrock 服务，在”Model access”页面中启用 Anthropic Claude 系列模型的访问权限。本文示例使用 Claude Sonnet 4 模型。
1 | # 创建新项目，指定 Python 版本为 3.13 |
依赖包说明：
bedrock-agentcore：AgentCore 的 Python SDK，提供运行时封装和服务集成strands-agents：Strands Agent 框架，简化 Agent 的构建过程bedrock-agentcore-starter-toolkit：部署工具包，提供 CLI 命令和自动化部署能力在项目根目录下创建 main.py 文件：
1 | from bedrock_agentcore import BedrockAgentCoreApp |
让我们详细分析每一部分代码的作用：
导入模块：
1 | from bedrock_agentcore import BedrockAgentCoreApp |
BedrockAgentCoreApp 是 AgentCore 应用的核心类。它封装了 HTTP 服务器、请求路由和生命周期管理，使您的 Agent 代码能够以标准化的方式运行，无论是在本地还是云端。
1 | from strands import Agent |
Agent 是 Strands 框架的核心类，负责管理对话流程、工具调用和模型交互。它提供了简洁的 API 来构建具有推理能力的 AI Agent。
1 | from strands.models import BedrockModel |
BedrockModel 是 Bedrock 模型的封装类，处理与 Amazon Bedrock 服务的通信，包括认证、请求格式化和响应解析。
创建应用实例：
1 | app = BedrockAgentCoreApp(debug=True) |
创建 AgentCore 应用实例。debug=True 参数启用调试模式，会输出详细的请求和响应日志，便于开发阶段排查问题。在生产环境中，建议将此参数设为 False。
配置模型：
1 | model = BedrockModel( |
model_id：指定使用的基础模型。这里使用 Claude Sonnet 4，us. 前缀表示使用美国区域的跨区域推理端点temperature：控制输出的随机性，范围 0-1。较低的值产生更确定性的输出，较高的值增加创造性max_tokens：限制单次响应的最大 token 数量，防止输出过长创建 Agent：
1 | agent = Agent( |
model：传入上面配置的模型实例system_prompt：系统提示词，定义 Agent 的角色和行为准则。这段文本会在每次对话开始时发送给模型，引导其行为定义入口函数：
1 |
|
@app.entrypoint 装饰器将 invoke 函数注册为 Agent 的入口点。当收到 HTTP 请求时，AgentCore 会自动调用此函数，并将请求体解析为 payload 字典传入。
1 | user_message = payload.get("prompt", "") |
从请求负载中提取 prompt 字段。使用 get 方法并提供默认值，可以安全地处理字段缺失的情况。
1 | if not user_message: |
输入验证：确保用户提供了有效的输入。返回的字典会被自动序列化为 JSON 响应。
1 | result = agent(user_message) |
调用 Agent 处理用户消息。Agent 会将消息发送给模型，获取响应，并在需要时执行工具调用。返回的 result 对象包含完整的对话结果。
1 | return {"response": result.message["content"][0]["text"]} |
从结果中提取文本响应并返回。result.message 是模型返回的消息对象，content 是内容数组，我们取第一个元素的 text 字段。
启动应用：
1 | if __name__ == "__main__": |
Python 的标准入口点检查。当直接运行此文件时，启动 HTTP 服务器。app.run() 默认在 0.0.0.0:8080 启动服务，这是 AgentCore Runtime 的标准端口。
启动 Agent：
打开终端，在项目目录下执行：
1 | uv run main.py |
您将看到类似以下的输出：
1 | INFO: Started server process [12345] |
发送测试请求：
打开另一个终端窗口，使用 curl 发送请求：
1 | curl -X POST http://localhost:8080/invocations \ |
运行结果示例：
1 | { |
从响应结果可以看到，Agent 成功接收了请求并返回了结构化的回答。响应时间约为 9 秒，这包括了模型推理的时间。
请求解析：
-X POST：指定 HTTP 方法为 POSThttp://localhost:8080/invocations：AgentCore 的标准调用端点-H "Content-Type: application/json"：设置请求头，表明请求体为 JSON 格式-d '{"prompt": "..."}'：请求体，包含发送给 Agent 的消息| jq .：将响应通过 jq 工具格式化输出（需要预先安装 jq）Agent 的真正威力在于能够调用外部工具来完成任务。接下来，我们将为 Agent 添加自定义工具。
1 | uv add strands-agents-tools |
strands-agents-tools 包含了一系列预构建的工具，如计算器、文件操作等。
更新 main.py 文件：
1 | from bedrock_agentcore import BedrockAgentCoreApp |
@tool 装饰器：
1 |
|
@tool 装饰器将普通 Python 函数转换为 Agent 可调用的工具。Strands 框架会自动：
类型注解的重要性：
1 | def get_weather(city: str) -> str: |
city: str：参数类型注解，告诉模型这个参数应该是字符串类型-> str：返回值类型注解，表明函数返回字符串类型注解不仅是代码文档，更是模型理解工具用法的关键信息。模型会根据这些信息决定如何构造工具调用参数。
Docstring 规范：
1 | """ |
Docstring 遵循 Google 风格，包含三个部分：
Args 部分：每个参数的详细说明，包括示例值Returns 部分：返回值的描述清晰的 docstring 能显著提高模型选择和使用工具的准确性。
带默认值的参数：
1 | def search_database(query: str, limit: int = 5) -> str: |
limit: int = 5 定义了一个带默认值的可选参数。模型可以选择是否提供此参数，如果不提供则使用默认值 5。
注册工具到 Agent：
1 | agent = Agent( |
tools 参数接受一个工具列表。calculator 是从 strands_tools 导入的内置工具，get_weather 和 search_database 是我们自定义的工具。
重启 Agent 后，测试不同类型的请求：
测试计算功能：
1 | curl -X POST http://localhost:8080/invocations \ |
Agent 会识别这是一个数学计算问题，自动调用 calculator 工具。
计算功能运行结果：
1 | { |
测试天气查询：
1 | curl -X POST http://localhost:8080/invocations \ |
Agent 会调用 get_weather 工具，传入参数 city="上海"。
天气查询运行结果：
1 | { |
测试复合任务：
1 | curl -X POST http://localhost:8080/invocations \ |
这个请求需要 Agent 协调多个工具：先查询天气获取温度，然后根据条件决定是否进行计算。
复合任务运行结果：
1 | { |
从这个结果可以看到，Agent 成功地：
get_weather 工具获取北京天气calculator 工具计算用电量Model Context Protocol（MCP）是一种标准化协议，允许 Agent 动态发现和调用工具。MCP Server 可以被任何支持 MCP 的客户端（如 Claude Desktop、Cursor、Kiro 等）调用。
1 | uv add mcp |
创建新文件 mcp_server.py：
1 | from mcp.server.fastmcp import FastMCP |
导入 FastMCP：
1 | from mcp.server.fastmcp import FastMCP |
FastMCP 是 MCP Python SDK 提供的高级封装类，简化了 MCP Server 的创建过程。
创建 MCP Server 实例：
1 | mcp = FastMCP( |
name：Server 的名称，用于标识和日志记录host：监听地址，0.0.0.0 表示接受所有网络接口的连接stateless_http=True：启用无状态 HTTP 模式，这是 AgentCore Runtime 要求的配置定义工具：
1 |
|
@mcp.tool() 装饰器将 Python 函数注册为 MCP 工具：
启动服务：
1 | mcp.run(transport="streamable-http") |
transport="streamable-http" 指定使用 Streamable HTTP 传输协议，这是 MCP 推荐的生产环境传输方式，支持流式响应。
启动服务：
1 | uv run mcp_server.py |
运行输出：
1 | MCP Server 启动中... |
使用 Python 客户端测试：
首先安装 MCP 客户端依赖（如果尚未安装）：
1 | uv add mcp httpx |
创建测试客户端文件 mcp_client.py：
1 | import asyncio |
代码解析：
1 | from mcp import ClientSession |
导入 MCP 客户端所需的模块：
ClientSession：MCP 客户端会话管理类streamablehttp_client：Streamable HTTP 传输客户端，用于连接使用该协议的 MCP Server1 | async with streamablehttp_client(mcp_url) as (read_stream, write_stream, _): |
建立与 MCP Server 的连接，返回读写流用于双向通信。
1 | async with ClientSession(read_stream, write_stream) as session: |
创建客户端会话并初始化，这会与服务器交换能力信息。
1 | tools = await session.list_tools() |
获取服务器提供的所有工具列表。
1 | result = await session.call_tool("add_numbers", {"a": 10, "b": 20}) |
调用指定工具，传入参数字典，返回执行结果。
运行测试：
确保 MCP Server 正在运行，然后执行：
1 | uv run mcp_client.py |
运行结果：
1 | 连接到 MCP Server: http://localhost:8000/mcp |
使用 curl 测试（CLI 方式）：
MCP Server 使用 Streamable HTTP 传输协议，需要设置正确的 Accept header：
1 | # 初始化连接 |
1 | # 列出可用工具 |
1 | # 调用 add_numbers 工具 |
curl 响应示例：
列出工具的响应：
1 | { |
调用工具的响应：
1 | {"jsonrpc": "2.0", "id": 3, "result": {"content": [{"type": "text", "text": "30"}]}} |
注意：curl 命令必须包含
-H "Accept: application/json, text/event-stream"header，否则会收到 “Not Acceptable” 错误。
使用 MCP Inspector 测试（可选）：
MCP Inspector 是一个可视化测试工具，提供图形界面来测试 MCP Server：
1 | npx @modelcontextprotocol/inspector |
在浏览器中打开 http://localhost:6274，选择 “Streamable HTTP” 传输类型，输入 MCP Server 地址 http://localhost:8000/mcp，即可进行交互式测试。您可以：
Agent-to-Agent（A2A）协议专为多 Agent 系统设计，允许 Agent 之间相互发现和通信。A2A 使用 JSON-RPC 格式进行通信，并通过 Agent Card 描述 Agent 的能力。
1 | uv add 'strands-agents[a2a]' |
创建新文件 a2a_server.py：
1 | import os |
导入 A2A 模块：
1 | from strands.multiagent.a2a import A2AServer |
A2AServer 是 Strands SDK 提供的 A2A 协议实现，需要安装 strands-agents[a2a] 扩展包。
环境变量配置：
1 | runtime_url = os.environ.get( |
从环境变量读取运行时 URL，如果未设置则使用本地默认值。这种设计使同一份代码可以在本地和云端运行，只需通过环境变量切换配置。部署到 AgentCore Runtime 时，该环境变量会自动设置。
创建 A2A Server：
1 | a2a_server = A2AServer( |
agent：要暴露的 Strands Agent 实例http_url：Agent 的可访问 URL，用于生成 Agent Card 中的端点信息serve_at_root=True：在根路径（/）提供服务，这是 AgentCore Runtime 要求的配置组合 FastAPI 应用：
1 | app = FastAPI(title="Calculator A2A Server") |
我们创建一个 FastAPI 应用作为容器，添加健康检查端点，然后将 A2A Server 挂载到根路径。A2A Server 默认使用 9000 端口，与 MCP Server（8000）和 AgentCore Runtime（8080）区分。
启动服务：
1 | uv run a2a_server.py |
获取 Agent Card：
1 | curl http://localhost:9000/.well-known/agent-card.json | jq . |
Agent Card 是 A2A 协议的核心概念，它描述了 Agent 的能力、支持的协议和调用方式。其他 Agent 可以通过读取 Agent Card 来了解如何与此 Agent 交互。
调用 Agent（使用 JSON-RPC 格式）：
由于我们创建的是 Calculator Agent（计算器 Agent），测试请求应该是数学计算相关的问题：
1 | curl -X POST http://localhost:9000/ \ |
请求格式解析：
jsonrpc：JSON-RPC 协议版本id：请求标识符，用于匹配响应method：调用的方法，message/send 是发送消息的标准方法params.message：消息内容role：消息角色，user 表示用户消息parts：消息内容数组，支持多模态（文本、图片等）messageId：消息唯一标识运行结果示例：
1 | { |
从响应可以看到，Calculator Agent 成功调用了 calculator 工具完成了数学计算，并返回了详细的计算过程。
在部署到云端之前，我们可以先在本地使用 Docker 容器运行 Agent。AgentCore Starter Toolkit 提供了便捷的 CLI 命令，可以自动生成 Dockerfile 并在本地构建运行容器，无需手动编写配置文件。
首先使用 agentcore configure 命令配置 Agent：
1 | agentcore configure -e main.py |
参数说明：
-e main.py：指定 Agent 的入口文件如果是首次运行，CLI 会以交互式方式引导您完成配置，包括设置 Agent 名称、选择区域等。您也可以使用 -ni（non-interactive）参数跳过交互式提示，使用默认值：
1 | agentcore configure -e main.py -ni |
执行后，CLI 会在项目目录下生成 .agentcore/ 配置目录，包含配置文件和 Dockerfile。
使用 agentcore launch --local 命令在本地 Docker 容器中构建并运行 Agent：
1 | agentcore launch --local |
此命令会自动：
运行输出示例：
1 | 🏠 Launching Bedrock AgentCore (local mode)... |
按 Ctrl+C 可以停止容器。
注意：
agentcore launch --local需要本地安装 Docker、Finch 或 Podman。
在另一个终端窗口中，发送测试请求：
1 | curl -X POST http://localhost:8080/invocations \ |
运行结果：
1 | { |
使用 agentcore launch --local 相比直接 uv run main.py 有以下优势：
如果您想了解 CLI 生成的 Dockerfile 内容，可以查看：
1 | cat .agentcore/Dockerfile |
生成的 Dockerfile 示例：
1 | FROM public.ecr.aws/docker/library/python:3.13-slim |
CLI 自动生成的 Dockerfile 遵循最佳实践，包括多阶段构建优化、依赖缓存等。
本地开发和容器化测试完成后，可以使用 AgentCore Starter Toolkit 将 Agent 部署到 AWS。
如果您在第六部分已经执行过 agentcore configure，可以直接部署。否则先配置：
1 | agentcore configure -e main.py |
部署 Agent：
1 | agentcore launch |
此命令会（默认使用 CodeBuild 云端构建）：
部署模式说明：
| 命令 | 构建位置 | 运行位置 | 说明 |
|---|---|---|---|
agentcore launch | 云端 (CodeBuild) | 云端 (AgentCore Runtime) | 推荐，无需本地 Docker |
agentcore launch --local | 本地 | 本地 | 本地开发测试 |
agentcore launch --local-build | 本地 | 云端 | 需要自定义构建时使用 |
测试云端 Agent：
1 | agentcore invoke '{"prompt": "你好，这是来自云端的测试"}' |
查看状态：
1 | agentcore status |
对于需要在 Jupyter Notebook 或 Python 脚本中进行更多控制的场景，可以使用 Python SDK：
1 | from bedrock_agentcore_starter_toolkit import Runtime |
配置输出示例：
1 | Bedrock AgentCore configured: /path/to/project/.bedrock_agentcore.yaml |
部署模式说明：
Python SDK 支持与 CLI 相同的三种部署模式：
1 | # 默认模式：CodeBuild 云端构建 + 云端部署（推荐） |
1 | # 预览将要删除的资源（不实际删除） |
问题： 启动时提示端口 8080 已被占用
解决方案：
1 | # 查找占用端口的进程 |
问题： 调用时报 AccessDeniedException
解决方案：
aws sts get-caller-identity问题： Agent 没有使用定义的工具
解决方案：
@tool 装饰器是否正确应用tools 列表问题： agentcore launch 执行时间过长
解决方案：
问题： 执行 agentcore launch --local 时报错：
1 | Multiple top-level modules discovered in a flat-layout: ['main', 'mcp_server', 'a2a_server', ...] |
原因： 项目目录中有多个 Python 文件（如 main.py、mcp_server.py、a2a_server.py 等），setuptools 无法确定哪个是主模块。
解决方案：
在 pyproject.toml 中添加 [tool.setuptools] 配置，明确指定要打包的模块：
1 | [project] |
添加 [tool.setuptools] 部分后，重新运行 agentcore launch --local 即可。
问题： 执行 agentcore launch --local 后，日志中出现大量重试警告：
1 | Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 1s. |
原因： 容器内的 OpenTelemetry 尝试将追踪数据发送到 localhost:4317（默认 OTLP 端点），但本地没有运行 OTLP 接收服务。
解决方案：
这个警告不影响 Agent 正常运行，可以忽略。如果想消除警告，可以禁用 OTLP 导出：
1 | agentcore launch --local \ |
本文详细介绍了 Amazon Bedrock AgentCore 的本地开发流程：
agentcore launch --local 在本地模拟生产环境agentcore launch 一键部署到 AWS通过本文的学习，您已经掌握了从本地开发到容器化测试，再到云端部署的完整流程。这种渐进式的开发方式能够帮助您：
本地开发与云端部署的无缝衔接，使开发者能够在保持高效迭代的同时，确保代码在生产环境中的可靠运行。
常规的MCP server 长这样，
1 |
如果要部署到云端的话，
1 |
默认会使用Agentcore runtime来启动，和sagemaker一样，需要有 /ping 和 /invokation的路由，并且容器host在8080端口，启动之后服务就会自动加一个网关来转发到这个应用的8080端口。
你可能还听见过Agentcore Gateway，这个是给一些其他的MCP server，Rest api或者。
甚至是apigateway和lambda。
启动之后，我们就会得到一个URL。
agentcore runtime的是
由于在url有arn，所以需要做一个http的转译，否则有些MCP的客户端可能无法处理识别这个。
agentcore gateway的是。
然后就是认证，Agentcore runtime接受JWT和IAM两种认证方式
而gateway除了这几种之外还可以接受无认证的方式。
这里我们重点介绍JWT的认证，一般是用于和SSO的集成，而这里的JWT通常指的是access token。
对于登陆系统而言，一开始使用用户名和密码登录之后，后端会返回一个JWT来代替用户的身份，然后我们把这个加在请求头里
请求头通常会这样写：
Authorization: Bearer <token>
Authorization 是 HTTP 标头中的一个字段。
Bearer 表示这是一个 Bearer token 类型。
<token> 是实际的访问令牌。
例如，假设你获得了一个 access token，它可能长成这个样子：
Authorization: Bearer abcdefghijklmnopqrstuvwxyz1234567890
登录：用户通过用户名和密码登录后，身份提供者（如身份认证服务器）生成一个 access token，并将其返回给客户端（例如，浏览器、移动应用）。
访问资源：客户端在需要访问受保护资源时（例如，API），会在请求中添加 Authorization: Bearer <token> 头部。这样，服务器就能知道这个请求背后是一个已经认证并授权的用户。
服务器验证：服务器接收到请求后，验证 Bearer token 是否有效。如果有效，服务器根据 token 中的权限信息返回相应的资源；如果无效或已过期，则拒绝访问。
向量数据库已经成为 AI 应用的核心基础设施。RAG 需要它存储知识库，Agent 需要它实现记忆，推荐系统需要它计算相似度，多模态搜索需要它做特征检索。从实验室到生产环境，向量检索已经是 AI 应用的标配能力。
但从入门到真正用好 Milvus，这条路并不短。
分布式架构需要理解——Proxy、Coord、Node 各司其职，一条查询请求在系统内部如何流转？Schema 怎么设计、Chunk 策略怎么选、混合搜索怎么配？与 LangChain、LangGraph 怎么集成？生产环境更是另一个战场——内存优化、写入调优、慢查询排查，每一个都是实打实的工程问题。
为了系统性地解决这些问题，我们整理了这份 《Milvus Workshop：从入门到应用》。
这份教程已经在多场线下 Workshop 中经过验证，帮助数百位开发者快速上手 Milvus。现在，我们上线了网页版——打开浏览器就能学，手机、平板、电脑无缝切换。
之前这份教程只有 GitHub 仓库版本，需要 clone 下来用 Jupyter 打开。代码能跑，但阅读体验受限，尤其在移动端几乎无法使用。
现在我们用 GitHub Actions 自动构建了 Web 版本：
通勤时间看架构原理，工作时间跑代码实操，学习效率显著提升。
整个 Workshop 分为四大模块，每章都以 Jupyter Notebook 格式呈现，所有代码可直接运行。同时也有对应的 Web 版本。
👉 想直接开始？ 点击这里打开教程
传统数据库擅长精确匹配：给定 ID 查记录，给定条件筛数据。但面对”哪些数据与这个最相似”这类问题，传统方案力不从心。
向量嵌入（Vector Embedding）将语义转化为数学表示。通过 Embedding 模型（如 BGE、E5、OpenAI text-embedding-3 等），文本、图片、音频等非结构化数据被映射为高维向量。语义相近的内容，向量空间中的距离也相近。
向量数据库的核心任务：在海量向量中高效检索最相似的 Top-K 结果。
精确的最近邻搜索需要遍历所有向量，数据量越大查询越慢，无法满足大规模数据的性能要求。ANN（Approximate Nearest Neighbor）通过构建索引结构，以可接受的精度损失换取数量级的性能提升。
| 索引类型 | 技术特点 | 适用场景 |
|---|---|---|
| FLAT（暴力搜索） | 精度 100%，无近似误差 | 小数据量、精度要求极高 |
| IVF 系列（IVF_FLAT / IVF_SQ8 / IVF_PQ） | 聚类分桶，量化压缩 | 中等精度、中等吞吐 |
| HNSW | 多层图结构，低延迟 | 高吞吐 + 高召回场景，适合推荐、搜索 |
| DiskANN | 基于图的磁盘索引 | 大数据量，有限内存场景，牺牲部分延迟 |
| GPU_IVF 系列 | GPU 加速版 IVF | 高吞吐、高并发场景，极致性能优化 |
| BIN_FLAT / BIN_IVF_FLAT | 二进制向量支持 | 文本、音频哈希类场景 |
IVF 系列是经典的聚类索引，通过将向量分桶实现快速检索，配合量化压缩可显著降低内存占用。HNSW 基于 Hierarchical Navigable Small World 图结构，查询性能优异，是当前最流行的索引类型之一。DiskANN 则适合内存受限但数据量大的场景，是性价比之选。
Milvus 采用存储计算分离的云原生架构，分为四层：
Access Layer：Proxy 节点负责接收请求、参数校验、路由分发。无状态设计，支持水平扩展。
Coordinator Layer：集群协调中心，包含四个组件：
Worker Layer：执行层节点：
Storage Layer：
Milvus 2.6 引入了 Streaming Node，专门处理实时数据流，进一步优化写入性能。
理解这套架构，对后续的问题排查和性能调优至关重要。
创建 Collection 时的关键决策：
Schema 设计直接影响后续的查询效率和灵活性，建议在编码前充分规划。
三个关键参数：
参数配置对性能影响显著，建议通过基准测试确定最优值。
向量搜索：
1 | results = collection.search( |
带标量过滤的搜索：
1 | results = collection.search( |
混合搜索：Milvus 2.4+ 支持同时使用稠密向量和稀疏向量（BM25），结合语义相似性和关键词匹配，通常能获得更好的检索效果。
CLIP 模型能够将图片和文本映射到同一向量空间，实现跨模态检索。
实现流程：
教程提供完整代码，涵盖模型加载、批量处理、检索实现。
RAG 是当前最主流的 LLM 应用模式，核心思路：先检索相关知识，再基于检索结果生成回答。
完整流程：
以下是 LangChain 集成示例：
1 | # 检索相关文档 |
关键优化点：
教程使用 LangChain 实现完整流程，并详细讨论这些优化策略。
Agent 的三大核心能力：规划（Planning）、记忆（Memory）、工具（Tools）。Milvus 在记忆系统中发挥关键作用。
短期记忆：当前会话的上下文信息，支持对话过程中的信息检索。
长期记忆：历史对话、执行经验、学习成果的持久化存储。遇到相似场景时，Agent 可以检索相关记忆，做出更优决策。
1 | # 存储对话记忆 |
教程使用 LangGraph 实现带记忆功能的 Agent，演示记忆的存储、检索和应用。
Milvus 原生支持 Prometheus 指标暴露。教程提供完整的可观测性方案：
提供开箱即用的 Dashboard JSON，涵盖 QPS、延迟、内存使用、Segment 状态等关键指标。
VectorDBBench 是 Zilliz 开源的向量数据库基准测试工具。上线前建议进行完整的性能测试，了解系统的 QPS 上限和延迟分布。
内存优化：
dataNode.segment.maxSize 控制 Segment 大小写入优化：
dataNode.flush.insertBufSize查询优化：
教程包含 Milvus 2.5 到 2.6 的升级指南，涵盖升级步骤和注意事项。
| 传统方式 | Web 版 | |
|---|---|---|
| 环境要求 | Git + Python + Jupyter | 浏览器 |
| 移动端体验 | 受限 | 完整支持 |
| 内容更新 | 手动 pull | 自动同步 |
📖 在线阅读：https://airag.click/milvus-workshop/
💻 GitHub 仓库：https://github.com/richzw/milvus-workshop
教程提供中英双语版本，欢迎 Star ⭐ 支持。我们将持续更新更多实战案例和最佳实践。
向量数据库的时代已经到来。无论是入门学习还是生产实践，这份教程都能提供有价值的参考。
Happy hacking 🚀
]]>前几天测试家里的网络，顺手重置了一下路由器。结果没想到，懒猫微服的 Wi-Fi 设置也跟着丢了。
打开网络设置一看，满屏都是邻居家的热点，就是没有我自己的。
没关系，懒猫毕竟是 Linux 系统，只要能够 开启 SSH，命令行就是万能钥匙。反正有分层文件系统，真要捣鼓坏了，重启也能恢复。
这次的主角是 nmcli，全称 NetworkManager Command Line Interface，它是 Linux 自带的网络管理命令行工具。
通俗点说，它是前端界面的“幕后操控者”——我们在图形界面上点击的“网络连接”“Wi-Fi 设置”，其实都在底层调用它。
有了 nmcli，我们几乎可以用命令完成所有网络操作：
| 功能 | 命令示例 |
|---|---|
| 列出可用 Wi-Fi 热点 | nmcli device wifi list |
| 连接 Wi-Fi | nmcli device wifi connect "SSID" password "12345678" |
| 查看当前网络状态 | nmcli connection show --active |
| 启用/禁用网卡 | nmcli device set wlan0 managed yes/no |
| 断开网络连接 | nmcli connection down id "MyWiFi" |
先 SSH 登录懒猫微服，直接使用 nmcli 扫描周边的 Wi-Fi：
1 | nmcli device wifi list |
这条命令会列出当前设备能检测到的所有 Wi-Fi 热点。
果然，我的 Wi-Fi 就静静地躺在输出列表里，只是前端页面没显示出来而已。
既然能看到 SSID，那就直接连接：
1 | sudo nmcli device wifi connect "MyWiFi" password "12345678" |
几秒钟后，终端提示：
1 | Device 'wlp129s0' successfully activated with 'xxxx-xxxx-xxxx' |
说明 Wi-Fi 已成功连接，懒猫顺利回到网络世界。
前面的命令会在命令行里明文显示密码。
其实 nmcli 也支持交互式连接，输入命令后系统会自动提示输入密码：
1 | sudo nmcli --ask device wifi connect "MyWiFi" |
这种方式既安全又方便，命令行历史不会留下明文密码。
连接成功后，可以用以下命令验证当前网络状态：
1 | nmcli connection show --active |
输出会显示所有活跃连接，包括 Wi-Fi、以太网、Docker 桥接等：
1 | NAME UUID TYPE DEVICE |
回到懒猫网络设置页面，就能看到熟悉的 Wi-Fi 已经连接上啦。
想断开连接也很简单，只要执行：
1 | nmcli connection down id "GL-MT3600BE-236-5G 1" |
系统会返回：
1 | Connection 'GL-MT3600BE-236-5G 1' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/17) |
轻松优雅，不需要点来点去。
]]>本文将手把手教你如何使用 Docker + Gunicorn + Lambda Web Adapter，将 Flask 应用部署到 Lambda，并通过 API Gateway 对外提供服务。
传统方式部署 Flask 到 Lambda 需要使用 Mangum、aws-wsgi 等第三方库，需要修改代码添加 handler。而 Lambda Web Adapter 是 AWS 官方方案，有以下优势：
1 | 客户端 → API Gateway → Lambda (Docker 容器) |
Lambda Web Adapter 作为 Lambda Extension 运行，负责将 API Gateway 事件转换为标准 HTTP 请求，Flask 应用完全感知不到自己运行在 Lambda 上。
确保你已安装：
创建项目目录和文件：
1 | mkdir flask-lambda && cd flask-lambda |
app.py - 一个简单的 Flask API：
1 | from flask import Flask, jsonify, request |
requirements.txt：
1 | flask==3.0.0 |
gunicorn.conf.py - 针对 Lambda 优化的配置：
1 | bind = '0.0.0.0:8080' |
Dockerfile：
1 | FROM python:3.11-slim |
核心就是这一行 COPY --from=...，它从 AWS 公共 ECR 仓库拉取 Lambda Web Adapter 二进制文件，放到 /opt/extensions/ 目录。Lambda 启动时会自动加载这个 Extension。
构建前先登录 ECR Public：
1 | aws ecr-public get-login-password --region us-east-1 | \ |
构建并运行：
1 | docker build --platform linux/amd64 -t flask-lambda . |
测试：
1 | curl http://localhost:8080/ |
本地没问题，接下来部署到 AWS。
1 | # 设置变量 |
首先创建 IAM 角色：
1 | # 创建信任策略 |
创建 Lambda 函数：
1 | aws lambda create-function \ |
打开 API Gateway 控制台，创建 REST API：
flask-api{proxy+}flask-api/ 创建 ANY 方法，集成到同一个 Lambdav1部署完成后，你会得到一个调用 URL，类似：
1 | https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/v1 |
1 | API_URL="https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/v1" |
🎉 大功告成！你的 Flask API 已经运行在 Lambda 上了。
如果你的 API 需要认证，可以在 API Gateway 中启用 IAM 认证。调用时需要对请求进行 SigV4 签名：
1 | import boto3 |
代码更新后，只需重新构建镜像并更新 Lambda：
1 | docker build --platform linux/amd64 -t flask-lambda . |
首次请求可能需要 1-2 秒（冷启动），可以通过以下方式优化：
AWS_LWA_ASYNC_INIT=true使用 Lambda Web Adapter，你可以：
这是“云端回家”的第一步。对很多人来说，NAS 不仅是一个硬盘，更是重新掌握数据主权的起点。
这篇文章就以最常见的百度网盘为例，演示如何将文件迁移到懒猫网盘中。
我们会介绍两种方式：
很多人习惯把资料放在百度网盘、腾讯微云、甚至 iCloud 上，但这些服务有一个共同点：你的数据都在别人的服务器上。
无论是隐私、速度，还是访问的自由度，都无法与自建 NAS 相比。
而懒猫网盘正好提供了一个简洁稳定的私有云方案：支持 SMB、WebDAV、HTTP 访问，同时能在内网高速读写，甚至还能开放公网远程访问。
因此，拿到 NAS 后，把百度网盘里的资料迁移过来，就成了多数用户的首要任务。
懒猫商店中自带的百度网盘 NAS 版本，其实是从群晖 Synology 移植过来的。
它提供了基础的上传、下载、同步功能，对于多数人来说已经足够。也无需再购买百度网盘 NAS 版本会员。
安装完成后，你会在 NAS 的根目录下看到一个名为 BaiduNetDiskNas 的文件夹。
这是百度网盘 NAS 套件默认的数据目录，所有通过该套件下载的文件都会存放在这里。
和其他套件不同，百度网盘的数据不会混进应用路径，而是直接落在 NAS 的根目录下，路径清晰，也方便后续迁移或备份。
使用方式很简单：
这种方式不需要额外配置，也不用动网络端口，适合初次上手懒猫网盘的用户。
因此，如果你希望速度更快、结构更灵活，可以继续看下面的第二种方案。
另一种更通用的方案，是使用 SMB（Samba）共享的方式。
简单来说，就是让你的电脑直接访问懒猫网盘的共享目录，把它当成本地磁盘使用。
这样一来，在百度网盘客户端中，就可以直接把下载路径设为 NAS 上的 SMB 共享文件夹，下载完成即同步到 NAS。
具体步骤如下：
在懒猫网盘中，进入【网盘 → 网络服务】，找到 SMB 服务内网开关，将其打开。
如果你有公网访问的需求，也可以使用懒猫提供的默认域名来挂载 SMB。
以 macOS 为例：
打开 Finder（访达） → 顶部菜单栏点击「前往」→「连接服务器…」
输入地址，例如：
1 | smb://192.168.1.4/用户名 |
如果你希望直接连接到某个子目录，也可以在后面加上路径，比如：
1 | smb://192.168.1.4/用户名/文件夹的名字 |
点击连接后，系统会提示输入用户名和密码。输入你在懒猫网盘中提示的账户信息即可。
连接成功后，你会在 Finder 的侧边栏看到 NAS 的共享文件夹。
打开百度网盘客户端 → 设置 → 下载路径 → 手动选择
此时选择你刚刚挂载的 NAS 共享目录。
我这里建了一个名为 “百度” 的文件夹，用于专门存放网盘迁移文件。
这样，百度网盘在下载文件时，实际上是直接把数据写进懒猫网盘中。
整个过程既不占用本机空间，也不需要二次传输，非常高效。
| 对比维度 | 百度网盘 NAS 套件 | SMB 中转迁移 |
|---|---|---|
| 安装难度 | 一键安装 | 需配置 SMB 服务 |
| 下载速度 | 一般（受限于百度接口） | 取决于本地带宽，通常更快 |
| 文件路径 | 固定在 BaiduNetDiskNas | 可自定义结构 |
| 适合人群 | 新手用户 | 进阶/高需求用户 |
| 依赖环境 | NAS 端运行 | NAS + 本地 PC 配合 |
总结一下：
如果你只想简单备份数据，百度网盘 NAS 套件足够；
如果你希望文件即时同步、可控性更强，SMB 中转方式更值得使用。
公有云的便利和便宜，确实让很多人习惯把所有资料交给它。
但当你真正拥有一台 NAS、部署起懒猫网盘那一刻，就会发现——数据掌握在自己手里的安全感，是任何会员都买不到的。
迁移数据只是第一步，之后你还可以：
无论你是第一次接触 NAS，还是从群晖、威联通迁移过来的老用户，希望这篇教程能帮你顺利完成“云端回家”的第一步。
]]>我倒宁可折腾一点，也要让录像回到自己掌管的地盘里。
毕竟人在江湖漂，出门在外，男孩子也得懂得保护好自己。
所以这次，我干脆把家里的摄像头，直接接入了懒猫微服。从此录像不走云，不怕会员断。
——这是懒猫微服的又一次实战升级。
如今的摄像头几乎都自带云存储功能，但云端录像的痛点大家都懂：
而懒猫微服就像一个沉稳的大侠，守得住隐私，也能接得住设备。它本质是一台私人云服务器，只要设备支持主流协议（SMB、RTSP 等），都能被纳入懒猫的怀抱——我今天接入的是一款中兴的摄像头。
摄像头原生支持 SMB 协议，这意味着它能直接把录像写进 NAS。
我们只需在懒猫微服的后台中，开启对应的服务即可：
路径：【网盘 → 网络服务 → SMB 服务内网开关】
懒猫的 SMB 模块非常稳定，能同时兼容 Windows、macOS、摄像头、甚至路由器的共享写入。
只要设好账号密码、IP 授权范围，就能实现局域网高速传输。
打开摄像头 App（我的是中兴智慧生活），
选择 “NAS 网络存储” 功能，并点击“手动添加”。
在地址栏中输入懒猫网盘的 IP 和账号凭证即可。一顿折腾之后终于可以了，中兴的程序员要上点心，抛异常要写具体，不管是密码不对还是啥错都报错不能匿名登陆。这样很误导人，真的有很多开发连 401 和 403 都傻傻分不清。
当摄像头成功连接后，你会在懒猫网盘里看到一个新文件夹——录像开始一段段被写入 NAS 中。
我这个摄像头录出来的文件是 MP4 格式，这点非常友好。懒猫网盘甚至能直接在线播放，也支持直接下载离线观看。如果想做 AI 识别或画面检索，还能直接喂进懒猫商店里的其他应用做视频分析。
由于我开了全天录制，记录保持一年，这个算是摄像头能够支持最大的限度了。可以看到懒猫网盘中一天的录像占用 7G 多一点，反正都有 NAS 了，算下来一年也就占用 2.6T，完全放得下，这可是用内存卡办不到的，借助懒猫微服的大容量存储，我们可以随时回滚到一年前的记忆。
从此我不必担心内存卡满、云端过期、账号异常。
所有录像都牢牢存在我自己的懒猫微服里，随时取、随时删、随时回看。
懒猫微服能接入的不止摄像头，它能接入的，是生活的秩序、家的安全感，以及我们对数字世界一点点的掌控力。
江湖很大，懒猫很静。
懒猫微服，不只是安静地趴在角落里。它能听、能看、能存、能守——是我出门在外最可靠的“家伙”。
折腾这些配置的过程，就像练武：一开始总会走火入魔，但掌握之后，心中自有一份安稳。
懒猫微服接入摄像头这件事，也许不是什么大事，但它让我更笃定——折腾，是生活的一种浪漫。
]]>/app/easysearch/logs/initialize.log 中找到，比如 exec 进入容器后直接 grep curl 搜索 Easysearch URI 字段，就能定位密码所在行。但现在——无论是 grep 还是手动翻，都空空如也。过去版本，Easysearch 初始化时会将自动生成的默认密码打印到日志文件中。
如下图所示，这样的日志路径在老版本中非常常见：
但在新版中，这条日志记录已经消失。
我平常习惯用 Dockage 来拉起 docker-compose，但由于日志滚动过快，输出信息一多也容易被覆盖。
在 Easysearch 的官方交流群中咨询后，得到了 CEO 本人的亲自回复：
新版之所以不再在日志中输出密码，是为了提高安全性，防止明文凭证泄露。
换句话说，密码仍然会在启动过程中生成，只是不再被重定向到容器内部的日志文件。
这意味着我们要换个思路，从 Docker 运行日志 中找密码。
新版的密码信息仍会在启动时输出，只是没落地到文件。
所以我们可以直接用 Docker 命令查看：
1 | docker logs <easysearch_container_name> | grep password |
在 macOS 上，用 Obstack 或 Dozzle 这样的图形化 Docker 日志工具也能非常直观地查看输出：
不过要注意：如果容器重启过多次，历史日志会被覆盖，因此建议在第一次启动时就及时复制密码。
其实完全可以避免手动找密码的麻烦——直接在启动 Easysearch 时自定义密码。
参考我之前的文章：
👉 启动 Easysearch 时自定义密码的操作方法
这样在 CI/CD 或本地部署时都能保持一致的密码配置，避免每次重启都要重新查找。
如果你已经错过了初始化日志，又没配置自定义密码，也不用慌。
热心群友提供了铭毅天下发布的官方重置方法，实测可行：
重置完成后系统会生成一个新的密码。
执行验证命令时，如果密码里有 !，要注意 zsh 的特殊行为。zsh 会把 ! 当作“历史命令展开符”，不转义会直接报错。
正确的写法如下：
1 | curl -ku admin:'!8We9L6@g6!NMZpEDx2Apn6U' https://localhost:9200 |
或者使用反斜杠转义：
1 | curl -ku admin:\!8We9L6@g6\!NMZpEDx2Apn6U https://localhost:9200 |
新版 Easysearch 不再在日志文件中明文输出密码，是出于安全强化的考虑。
要找密码，可以：
docker logs 查看启动日志；虽然麻烦了一点，但这确实是更安全、更企业化的做法。
]]>这意味着，只要一层反向代理（reverse proxy）去转发 HTTPS 请求，TLS 校验就会报错。
这不是配置错误，而是 SSL 的“安全特性”在起作用。
本文就带大家看看如何在懒猫微服上架过程中如何优雅地解决这一问题。
假设我们要在懒猫微服上架一个 App，用来转发请求到后端的 Easysearch 搜索引擎。
项目的 manifest（lzc.yaml）配置如下：
1 | lzc-sdk-version: "0.1" |
这段配置的意思很简单：
当访问 proxy.lzcapp.xxx 时，请将请求转发到容器内的 https://easysearch:9200/。
然而在 Dozzle 日志中，你会看到熟悉的报错信息：
1 | 2025/10/08 10:20:15 http: proxy error: tls: failed to verify certificate: x509: certificate is valid for infini.cloud, *.infini.cloud, not easysearch |
报错很直白：
证书仅对
infini.cloud和*.infini.cloud有效，而不是easysearch。
这正是 证书域名不匹配（SNI mismatch） 的典型例子。
在 HTTPS 连接建立过程中，客户端（此处是反向代理）会验证服务器返回的证书：
而我们的容器内部通常使用服务名（例如 easysearch）访问，不是证书上写的正式域名（infini.cloud）。
这就造成了验证失败。
在浏览器中，如果你访问一个自签名 HTTPS，会看到类似提示：“连接不安全”。
在反向代理中，它不会弹窗，而是直接抛出异常中断。
在以前的实验中，我用过 Nginx 来转发自签名 HTTPS 的 Easysearch，发现并没有报错。
这是因为——Nginx 默认不会验证上游 HTTPS 证书。
在官方文档 ngx_http_proxy_module 中明确写道：
Syntax:
proxy_ssl_verify on | off;> Default:proxy_ssl_verify off;> Context: http, server, locationThis directive sets whether to verify the SSL certificate of the proxied server.
也就是说：
proxy_ssl_verify 是 off；proxy_ssl_verify on; 时，它才会去核对证书域名、签发方、有效期等信息。这点在内部网络部署中非常有用 —— 因为大部分内网服务使用的都是自签名或临时证书。
要更直观理解，我们先构造一个简单的实验场景。
下面是一个 Docker Compose 配置，启动一个 Easysearch 容器和一个 Nginx 容器：
1 | version: "3.8" |
Nginx 配置如下：
1 | events {} |
这个配置里没有加任何 SSL 校验相关指令。
Nginx 在请求 https://easysearch:9200 时会直接忽略自签名问题，代理层不会抛错。
懒猫微服默认 app.proxy 是 OpenResty（Nginx 增强版） 。
它天然具备和 Nginx 一样的 SSL 默认策略 —— 即忽略内网自签名的证书验证。
外挂的配置文件很麻烦，我们可以使用 setup_script 来执行 shell 命令来动态写入。效果和前面是一样的。
1 | lzc-sdk-version: "0.1" |
这段配置中，setup_script 会在容器启动时执行，会动态写入 Nginx 配置文件。
容器之间的通信使用内网域名，不校验证书。这样代理转发就能成功，日志也不会再出现 x509 错误。
如果你不想写配置文件，懒猫官方提供的 app-proxy 镜像还支持 UPSTREAM 环境变量 来简化操作：
1 | lzc-sdk-version: "0.1" |
这种方式更轻量，也便于在应用市场中复用。
UPSTREAM 会自动注入到镜像配置中，无需手动挂载文件。
upstreams 支持 SSL 开关懒猫微服新版本的 SDK 进一步增强了反向代理的灵活性。
你可以直接在 application 部分的 upstreams 中声明多个后端服务，并显式配置 SSL 行为：
1 | lzc-sdk-version: "0.1" |
当 disable_backend_ssl_verify: true 设置后，平台在代理时会自动跳过证书校验步骤。
这相当于在 Nginx 中使用了：
1 | proxy_ssl_verify off; |
部署后日志如下：
1 | PATH:"/" is served by {/ false https://easysearch:9200 false true false false [] false false []} |
代理成功生效。
通过本文的两种方法，我们可以：
未来如果要接入多后端服务的多路复用机制也能轻松应对。
]]>反向代理不仅是“流量的中转站”，更是“安全与兼容的缓冲层”。
理解 SSL 校验机制后，才能写出既安全又高可用的微服务架构。
它产品线齐全、价格诱人、在亚马逊上好评不少，却始终无法在玩家社区中形成话题。为什么？本文试图从定位、生态、产品、传播与竞争格局五个维度剖析这家“沉默的 NAS 厂商”。
铁威马成立于 2002 年，最初做的是DAS（Direct Attached Storage）和 RAID 阵列柜，在 DIY 和视频剪辑圈里有一定口碑。
但它与群晖、威联通最大的区别是：
铁威马一直是一个“硬件思维主导的软件厂商”。
对比来看：
| 品牌 | 产品核心 | 技术策略 | 典型用户群 |
|---|---|---|---|
| 群晖 Synology | 软件（DSM 系统） | 打造生态闭环、重体验 | 家庭用户、中小企业 |
| 威联通 QNAP | 软件 + 硬件多元化 | 丰富功能与性能路线 | 技术型企业用户 |
| 铁威马 TerraMaster | 硬件性价比 | 以成本与兼容性为卖点 | 入门级、预算型用户 |
铁威马的 T 系列 NAS 硬件性能并不差，甚至同价位下 CPU、内存、网口规格往往更高，但它缺少软件体验层面的“惊喜”——这让它看起来更像“带系统的硬盘盒”，而不是一个“私有云平台”。
铁威马自研的操作系统 TOS（TerraMaster OS）目前发展到 TOS 6.x，在 UI 设计与易用性上已有改进，但生态仍是最大痛点。
| 对比项目 | 群晖 DSM 7.x | 威联通 QTS / QuTS | 铁威马 TOS 6 |
|---|---|---|---|
| 系统界面 | 精致、流畅、统一 | 丰富但复杂 | 简单但略显老旧 |
| 应用中心 | 200+ 官方/第三方 | 300+ 插件生态 | 40+ 应用，更新慢 |
| 虚拟化支持 | Docker、VM、Kubernetes | 虚拟机中心、容器站 | 仅部分机型支持 Docker |
| 安全更新 | 定期推送、活跃社区 | 补丁频繁 | 更新周期长、文档少 |
| 云服务集成 | Synology Drive、Photos、C2 | myQNAPCloud | CloudSync |
结果是，TOS 虽然能满足基础文件共享、RAID 管理、Time Machine、备份任务等需求，但缺乏高级功能——例如群晖的 Active Backup、威联通的 QuMagie AI 照片识别、或多云同步整合。
这导致许多中高端用户在体验后觉得：
“功能够用，但系统太单调。”
群晖有论坛、有教程、有博主内容；威联通有 NAS 玩家社区、有 QTS 更新直播；
而铁威马呢？
除了官网更新日志和亚马逊评论，几乎没有声音。
缺乏社区意味着：
这让铁威马在舆论层面处于“隐身”状态——普通用户不知道它，玩家不讨论它，企业客户不了解它。
甚至有种“用过就忘”的品牌感。
铁威马所处的价格区间（千元～三千元）正好是最卷的 NAS 市场。
但它的两侧都被强敌包夹：
于是，铁威马成了“想省钱又不想折腾”的那群人唯一的选项——但这群人，数量其实有限。
在全球市场上，铁威马的销售策略更接近传统 OEM 模式：靠亚马逊、电商分销、批发代理出货。
它几乎没有参与 Reddit、Discord、YouTube 技术社区的长期运营，也少有海外测评博主合作。
搜索“TerraMaster NAS”时，能看到的都是散乱的用户测评，而非系统的品牌叙事或技术展示。
而群晖、威联通早已形成“生态势能”：更新一个版本，都能被科技媒体报道。
恰恰相反，它有几个被低估的优势：
如果你只是想：
铁威马依然是“买了不亏”的选择。
铁威马的问题，不在产品，而在定位和传播。
它不是“做不好”，而是“不被看到”。
在一个重体验、重生态的市场中，仅靠“硬件性价比”已经难以立足。
铁威马需要做的不仅是提升性能，而是讲清楚自己是谁——
是要做“平价 NAS”，还是“轻企业私有云”？
是要成为入门市场的守护者，还是中小企业的替代方案？
否则，它可能继续像现在这样：
]]>默默出货，默默被遗忘。
除了搜索和信息整理之外，Coco AI 还提供了一个完善的 插件系统。通过插件，它几乎可以控制电脑的方方面面：
操作本地备忘录、播放音乐、查找应用，甚至取代 macOS 的导航栏。更令人惊喜的是，它还内置小游戏，比如大家熟悉的 2048。
Coco AI 的插件系统不是简单的第三方扩展，而是深度整合在 macOS 桌面环境中的轻量级功能模块。
例如下图中的界面，插件可以直接访问系统级服务：
通过插件，Coco 能够直接读取或编辑本地备忘录、打开 Finder 文件夹、启动已安装的应用，甚至接管顶部导航栏，让桌面控制更加一体化。
在使用体验上，这些功能完全不需要额外配置。插件启用后，会自动加载到 Coco 的主控制界面，执行速度快，界面响应流畅。
音乐爱好者会发现，Coco 的插件生态对媒体控制支持得非常完善。
它不仅支持系统自带的音乐播放器，还能直接控制第三方软件，例如网易云音乐、QQ 音乐等。
在开启相关插件后，你可以在 Coco 面板中完成播放、暂停、切歌、调节音量等操作。
对于喜欢边工作边听歌的人来说，这种“中控台式”的体验比单独切换应用更加高效，也更美观。
除了控制音乐和笔记，Coco 还有一些插件能替代 macOS 顶部的系统导航栏。
得益于 Coco 的统一框架，导航栏可以和其他插件联动，这种深度整合的插件体验，使得 Coco AI 更像是一个“桌面操作系统的延伸层”，而不只是一个 AI 应用。
在主界面右上角点击“加号”，就能打开 插件商店（Plugin Store）。
每个插件都有简介、开发者信息、版本号和一键安装按钮。安装后插件会立即生效，无需重启。
商店的搜索栏也很实用，可以直接输入关键词查找插件。例如输入 “2048”，就能找到一款完整的小游戏插件。
工作之余，Coco 还可以成为一个放松工具。
在插件商店中搜索 “2048”，即可找到一款轻量化的本地小游戏。
安装完成后，打开 Coco 的插件区即可直接启动游戏。
整个界面与经典的 2048 完全一致，采用极简配色，操作流畅，不需要联网，也没有广告。
使用方向键控制方块合并，当数字达到 2048 时即可获胜。
游戏支持自动保存分数，下次打开可以继续上局，非常适合在短暂休息时消遣。
Coco AI 的插件商店展示了一个轻量、开放、可扩展的桌面生态。
它将搜索、系统操作、音乐控制、任务管理、小游戏等多种功能融合在一个统一界面中。
对用户而言，Coco 的价值不仅在于“能干什么”，而在于“减少多少步骤”。
从打开备忘录、播放音乐，到临时玩一局 2048，所有操作都能在一个窗口内完成。
这种无缝衔接的体验，正在重新定义智能工具的形态——Coco 不再只是一个 AI 程序，而更像是 macOS 的「智能插件中心」。
]]>本视频探讨了人们在生活和工作中常常陷入缺乏话语权的小团体中的现象。这些小团体包括项目组、朋友聚会、家庭关系网等，表面上看似平等，但实际上存在权力关系，导致部分人的声音被忽视、观点不被重视。
本视频强调了在缺乏话语权的环境中长期停留的负面影响，并鼓励人们勇敢寻找能让自己发声、被尊重的环境。通过真实表达和被倾听，实现自我价值和内心的平静。
]]>视频强调了拥有一个输出型爱好对个人成长和心理健康的重要性。在信息爆炸的时代，人们往往陷入被动消费的循环，而忽视了主动创造的价值。通过输出，我们不仅能够将知识转化为自己的智慧，还能在创作过程中获得成就感和满足感，从而对抗现代生活的空虚与疲惫。
拥有一个输出型爱好，不仅是一种生活方式的转变，更是一种自我实现的途径。它让我们在信息洪流中保持清醒，在被动消费中找回主动创造的力量。从今天开始，尝试找到属于你的输出方式，让生活因创造而更加丰富多彩。
]]>改变自己的最快方式是早起并进行密集做事。通过早起，我们能够抓住一天中大脑最清醒的黄金时间，进行高效、专注的行动，从而实现自我提升和人生转变。
早起和密集做事是一种生活方式，也是一种对自我的承诺。它不仅改变了你的生活，也在重塑你的灵魂。从今天开始，让早起和高效工作成为你改变自己的力量，让每一个清晨都见证你迈向更好的自己。
]]>传达信息
建立关系
推动行动
言前思虑
多听少说
避免情绪化表达
本文将详细介绍在 docker run 启动 Easysearch 容器时，通过不同方式传入环境变量（env）来自定义密码的多种方法。每种方法都配有实用示例和说明，帮助你根据实际环境灵活选择。
这是最简单、最直接的方式，适合快速启动或临时测试场景。
1 | docker run --name easysearch \ |
启动完成后，可进入容器验证变量是否生效：
1 | docker exec -it easysearch bash |
输出结果：
1 | passwd123 |
这个是在容器内部查看 ENV 的结果：
✅ 优点：
⚠️ 缺点：
如果你需要设置多个变量或希望更好地管理配置，建议使用 .env 文件。
这种方式清晰、安全、易于维护，是 最推荐的做法。
.env 文件在当前目录下新建 .env 文件：
1 | EASYSEARCH_INITIAL_ADMIN_PASSWORD=envfile123 |
1 | docker run --name easysearch \ |
验证变量：
1 | docker exec -it easysearch bash |
输出：
1 | envfile123 |
✅ 优点：
⚠️ 注意事项：
.env 文件路径需正确（相对或绝对路径）；
变量中含有空格或特殊字符时请用引号包裹：
1 | EASYSEARCH_INITIAL_ADMIN_PASSWORD="P@ss word!123" |
💡 补充说明：
.env 文件会自动读取；docker run 时，必须显式指定 --env-file。当宿主机上已经定义了某些变量时，也可以直接将它们传递给容器。
这种方式非常适合自动化脚本和 CI/CD 场景。
1 | export EASYSEARCH_INITIAL_ADMIN_PASSWORD=hostenv123 |
1 | docker run -e EASYSEARCH_INITIAL_ADMIN_PASSWORD \ |
或：
1 | docker run --env EASYSEARCH_INITIAL_ADMIN_PASSWORD \ |
验证变量：
1 | docker exec -it easysearch bash |
输出：
1 | hostenv123 |
✅ 优点：
⚠️ 注意：
printenv 查看宿主机变量。在生产环境中，建议不要直接在 .env 文件或命令行中存储密码。
可以结合以下工具来安全地管理敏感信息：
.gitignore**：确保 .env 文件不被提交到代码仓库。无论采用哪种方式，都可以使用以下命令验证：
1 | docker exec -it easysearch env | grep EASYSEARCH_INITIAL_ADMIN_PASSWORD |
或：
1 | docker inspect easysearch | grep EASYSEARCH_INITIAL_ADMIN_PASSWORD |
若输出包含你的密码值，即表示设置成功。
| 方式 | 适用场景 | 安全性 | 便利性 | 是否推荐 |
|---|---|---|---|---|
| 命令行直接传入 | 快速测试 | ⭐ | ⭐⭐⭐ | ❌ |
.env 文件 | 开发/测试 | ⭐⭐ | ⭐⭐⭐⭐ | ✅ |
| 宿主机变量 | 自动化部署 | ⭐⭐⭐ | ⭐⭐⭐ | ✅ |
| Secret 工具 | 生产环境 | ⭐⭐⭐⭐ | ⭐⭐ | ✅✅✅ |
假设我们要在生产环境部署，并定义多个参数：
.env 文件内容如下：
1 | EASYSEARCH_INITIAL_ADMIN_PASSWORD=${EASYSEARCH_PASS:-default123} |
启动命令：
1 | EASYSEARCH_PASS=SuperSecret123 \ |
此时：
EASYSEARCH_PASS，则使用该值；.env 文件中的默认值 default123。在 Docker 环境中配置 Easysearch 初始密码的常用方式主要有三种：
🚀 最佳实践建议：
- 开发环境使用
.env文件；- 生产环境使用 Secret 管理；
- 将
.env文件加入.gitignore；- 定期轮换密码，确保安全。
参考命令：
1 | docker run --name easysearch \ |
1 | version: "3.3" |
easysearch.yml。其实，Docker 天生就支持通过环境变量来传递参数。
只要我们把要改的配置写进 .env 文件，再用 --env-file 加载，就能在启动时覆盖 easysearch.yml 的对应设置。
这样，既不用改镜像，也不用动配置文件，还能方便地调试、切换和管理。
下面就来详细讲讲这套思路的原理、写法与实践。
Docker 启动容器时，会把宿主机上的环境变量传递进容器内部。
容器里的程序（例如 Easysearch）在启动时，会读取这些变量并用来覆盖或替代默认配置。
简单来说：
1 | 环境变量 > easysearch.yml > 默认值 |
也就是说，只要我们在启动容器时提供了对应的环境变量，就能覆盖掉配置文件里的同名参数。
这就是“用 Docker 环境变量替代修改配置文件”的原理。
.env 文件写法先准备一个 .env 文件（放在和 Docker 命令同级的目录下）：
1 | EASYSEARCH_INITIAL_ADMIN_PASSWORD=envfile123 |
这几个变量的含义如下：
| 变量名 | 功能 | 说明 |
|---|---|---|
EASYSEARCH_INITIAL_ADMIN_PASSWORD | 初始化管理员密码 | 推荐通过环境变量传递，安全又方便 |
cluster.name | 集群名称 | 多节点部署时保持一致 |
elasticsearch.api_compatibility | 是否启用 ES API 兼容模式 | 一般设为 true，方便客户端兼容 |
node.name | 节点名称 | 区分不同节点 |
network.host | 监听地址 | 0.0.0.0 表示允许外部访问 |
.env 文件的格式非常简单，每行一个 key=value，不要有多余空格，也不要加引号。
文件放在项目目录下即可，Docker 会自动读取。
.env 文件注入配置启动命令示例：
1 | docker run -d \ |
这里的 --env-file ./.env 参数告诉 Docker 从 .env 文件中加载变量。
Docker 会自动把 .env 中定义的内容注入到容器环境中，EasySearch 启动时就会自动读取。
如果你想在启动时再临时改动一个参数，可以直接加 -e 选项：
1 | docker run -d \ |
这时候命令行里的 -e 会优先于 .env 文件的值。
容器启动完成后，可以用 curl 验证 EasySearch 是否按 .env 中的配置运行。
1 | curl -s -u admin:envfile123 http://localhost:9200 |
你会看到类似输出：
1 | { |
几个关键字段说明环境变量确实生效：
"name": "node-1" 来自 node.name"cluster_name": "mysearch" 来自 cluster.nameEASYSEARCH_INITIAL_ADMIN_PASSWORD 已应用如果想确认容器里到底有哪些环境变量，可以执行：
1 | docker exec easysearch env |
1 | ➜ 未命名文件夹 14 docker exec easysearch env |
或者只看我们关心的部分：
1 | docker exec easysearch env | grep EASYSEARCH |
这样能清楚看到 .env 文件中定义的变量是否真的被传进去了。
如果某个值缺失或拼写错误，这个方法很容易排查。
在 Docker 镜像中，EasySearch 通常有一个默认的 easysearch.yml。
当容器启动时，程序会按以下优先级加载配置：
-e 指定的环境变量--env-file 传入的变量/etc/easysearch/easysearch.yml 文件因此，当你通过 .env 或 -e 设置参数后，这些值会覆盖配置文件里的同名项。
你完全不需要去修改容器内部的配置文件。
这正是现代容器化部署推荐的做法：
配置文件保持模板化，动态参数全部用环境变量注入。
.env.example 模板在项目目录中放一个 .env.example 文件，内容示例化：
1 | EASYSEARCH_INITIAL_ADMIN_PASSWORD=changeme |
其他成员部署时只需复制：
1 | cp .env.example .env |
再修改必要的值即可。
.env 不要进版本库把 .env 加入 .gitignore，避免把真实密码上传。
.env 文件区分环境你可以创建多份环境文件：
1 | .env.dev |
启动时指定不同的文件：
1 | docker run -d --env-file ./.env.dev ... |
这样一套镜像就能跑多个环境，彻底解耦配置与部署。
通过 Docker 的环境变量机制，我们可以：
easysearch.yml；.env 文件集中管理参数；从此以后，部署 EasySearch 只需要两步：
.env；docker run --env-file 命令。所有的参数都能即时生效，配置文件原封不动。
这就是现代容器化运维的思路：
“配置解耦、参数注入、环境即定义。”
当你下次用 curl 看见返回里显示的cluster_name: mysearch、name: node-1，
那就是 .env 的功劳——
再也不用去翻 easysearch.yml。
别名可以在创建索引时定义，也可以在已有索引上添加。
1 | PUT /logs_2025-10 |
该操作创建索引 logs_2025-10，并同时定义一个别名 logs_current。
之后，所有针对 logs_current 的查询都会路由到 logs_2025-10：
1 | POST logs_2025-10/_doc |
1 | POST /logs_2025-10/_alias/logs_current_v2 |
或者使用 _aliases 批量操作：
1 | POST /_aliases |
默认情况下，别名仅支持查询。
如果一个别名指向多个索引，那么写入（POST /alias/_doc）操作会报错。
1 | { |
为了解决这一问题，可以通过 is_write_index 参数指定某个索引作为写入目标。
1 | POST /_aliases |
此时：
GET /logs_all/_search 会同时检索两个索引；POST /logs_all/_doc 时，数据会写入 logs_2025-10。
别名的最大优势之一是实现索引的无缝切换。
例如，应用程序始终通过 logs_all 查询数据，而底层实际索引会按天数变化。
切换示例：
1 | POST /_aliases |
这里我移除了 logs_2025-10-01，然后添加了 logs_2025-10-03。
可以使用GET /_cat/aliases?v查看。
别名还可以定义过滤条件，控制用户只能看到部分数据。
这是实现数据分区视图或权限隔离的常见方式。
它展示如何让一个别名只返回 region=china 的文档，而不暴露其他地区的数据。
1 | PUT /transactions |
刷新索引：
1 | POST /transactions/_refresh |
定义一个只允许访问中国区数据的别名：
1 | POST /_aliases |
1 | GET /transactions_cn/_search |
返回结果类似：
1 | { |
可以看到：
usa 和 japan 的记录不会出现在结果中；term 条件。
Elasticsearch 的数据分片（sharding）是通过一个公式决定的：
1 | shard = hash(routing) % number_of_primary_shards |
_id因此：
把别名和 routing 绑定起来，可以实现“逻辑分区 + 性能优化 + 查询隔离”。
下面通过一个完整的数据例子演示。
1 | PUT users |
1 | POST /_aliases |
✅ 我们现在有两个逻辑视图：
| Alias | Routing | 用途 |
|---|---|---|
users_cn | "china" | 代表中国用户 |
users_us | "usa" | 代表美国用户 |
1 | POST users_cn/_doc |
✅ 实际都写入到同一个物理索引 users，
但数据被根据 routing（china / usa）分到了不同分片。
1 | GET users/_search_shards |
返回示例：
1 | { |
1 | GET users_cn/_search |
输出：
1 | { |
1 | GET users_us/_search |
输出：
1 | { |
1 | GET users/_search |
返回所有 4 条记录，因为没带 routing。
1 | POST /_aliases |
然后查询：
1 | GET users_adults/_search |
→ 只返回 王芳（34 岁）和 John（42 岁）和 Emily（31 岁）。
。
| 场景 | routing 带来的好处 |
|---|---|
| 写入 | 相同 routing 的文档总是写入同一分片，减少 shard 跳转 |
| 查询 | 查询时只访问一个 shard，速度可提升数倍 |
| 多租户 | 每个租户 routing 不同，实现物理隔离 |
| 地域分区 | 中国区、美国区等逻辑分区共享同一个索引 |
查看当前集群中所有别名：
1 | GET /_cat/aliases?v |
输出结果：
1 | alias index filter routing.index routing.search is_write_index |
删除别名：
1 | DELETE /logs_2025-10/_alias/logs_current |
或：
1 | POST /_aliases |
Easysearch 的索引别名是一个轻量、强大且几乎“零成本”的机制，它在索引生命周期管理中起着核心作用。
合理使用别名，可以实现：
对于任何生产环境的 Easysearch 集群来说，别名是不可或缺的基础能力。
]]>一个是面向搜索与分析的分布式引擎，一个是面向事务与一致性的关系型数据库。
而当我们深入理解它们的数据结构定义方式——ES 的 自动 mapping 推断 与 MySQL 的 手动 schema 定义——就会发现，它们的核心设计理念几乎是两个世界。
本文将从机制、原理、优缺点和使用建议等角度，系统对比两者的差异，重点聚焦在 Elasticsearch 的自动 mapping 特性上。
在 MySQL 中，我们习惯使用 表结构（Schema） 来定义数据字段及其类型：
1 | CREATE TABLE user ( |
每一行都必须严格遵守这个表结构，类型固定，字段不可缺少。
这是典型的 Schema-first 模型：在写入之前必须定义好结构。
而在 Elasticsearch 中，索引（Index）虽然也有 schema 概念，但它是通过 Mapping 来定义字段类型和分析方式的。
Mapping 可以手动声明，也可以让 ES 自动推断。例如：
1 | POST /user/_doc |
ES 会自动创建 user 索引，并根据字段值类型生成如下 mapping：
1 | { |
这就是 自动 mapping（dynamic mapping）：ES 在第一次看到某字段时自动推断类型并写入 mapping。
不需要提前定义结构，系统“自学习”出 schema。
Elasticsearch 的 mapping 推断是动态的（Dynamic Mapping）。当写入新文档时，ES 会：
_mapping；例如：
| 值 | 推断类型 | 备注 |
|---|---|---|
"hello" | text + keyword | 同时支持全文检索与精确匹配 |
123 | long | 数值型 |
12.3 | double | 浮点型 |
"2025-10-05" | date | 自动识别日期格式 |
true | boolean | 布尔值 |
ES 的这种自动识别让开发者在数据探索早期几乎零配置即可使用，非常便捷。
但这种便捷背后也隐藏着风险——错误推断、类型冲突、mapping 爆炸等问题可能在后期放大。
与 ES 不同，MySQL 属于 强类型、静态结构 模型。
它要求所有字段在写入前就被定义好。任何表结构变更都需要执行 ALTER TABLE，会产生锁表或重建索引的代价。
优点是：
缺点则是：
如果说 MySQL 的 schema 是“一座刚性大厦”，那 ES 的 mapping 就像“可随时扩建的集装箱”。
在日志、埋点、IoT 等场景中，数据字段极多且经常变化。
自动 mapping 让开发者无需提前规划字段，只要把 JSON 写进去，ES 就能立刻索引和查询。
例如日志：
1 | { "host": "server-1", "response_time": 123, "status": 200 } |
即使第二条日志多了新字段：
1 | { |
ES 也会自动为 region 增加字段定义，无需手动修改 mapping。
这在 MySQL 中则必须执行结构变更。
ES 的索引不要求所有文档字段一致。某些文档可以缺字段而不影响写入。
对动态 JSON 数据、日志、监控事件特别友好。
数据可来自多源系统（API、Kafka、日志流），字段差异大。
自动 mapping 让这些异构数据能快速进入索引，后期再统一分析。
在数据探索阶段，不必先定义 schema，就能立刻搜索和聚合，是数据科学家和分析工程师最喜欢的特性之一。
ES 根据值内容推断类型，但不是总能猜对：
| 原始值 | 被推断类型 | 潜在问题 |
|---|---|---|
"00123" | text | 实际上是字符串数字 |
"2024/12/01" | date | 格式异常可能被误识别 |
123.0 | double | 实际希望 long，却被识别为浮点 |
true / false | boolean | 可能来自字符串而非布尔值 |
类型一旦被推断并写入 mapping，就无法修改。
如果写错，只能重建索引并重新导入数据。
ES 的每个字段都要占用堆内存（field data、倒排索引、统计信息）。
当系统存在动态命名字段（如 user_1, user_2, …）时，会生成成千上万个字段，导致：
官方建议：单个索引字段数不要超过 1000。
ES 中字段一旦创建，类型就锁定。
比如第一次写入 "price": "123" 被识别为 text，之后再写入数字 price: 123 就会报错：
1 | mapper_parsing_exception: cannot merge a field of type [long] with [text] |
修复方法只有一个：重建索引。
自动 mapping 对 string 默认生成 text + keyword 两种字段。
在全文检索时 OK，但在聚合、排序、精确匹配时会引发困惑。
许多用户在 Kibana 中查询 "region.keyword" 才能聚合，是由 mapping 自动生成机制决定的。
相比之下，MySQL 的 schema 固定、类型严格，所有字段定义都在 DBA 控制下。
这意味着：
在交易、账务、库存、财务等场景中，MySQL 的稳定性远胜 ES。
它的缺点恰恰是 ES 的优点：灵活性差但可控。
ES 提供了几种方式，在保留灵活性的同时减少风险。
你可以为自动推断加“模板规则”：
1 | { |
这样所有 _id 结尾的字段都被强制识别为 keyword，而不是 text。
在生产环境常见做法是：
1 | { "dynamic": "strict" } |
意味着：未定义字段禁止写入。
防止误导入数据结构。
1 | PUT /my_index/_settings |
避免 mapping explosion。
对关键字段（时间戳、数值、地理位置、ID）手动声明类型。
剩余部分交由 dynamic mapping 自动处理，可兼顾灵活与安全。
| 指标 | Elasticsearch | MySQL |
|---|---|---|
| 写入性能 | 较高（分布式、异步） | 较低（事务同步） |
| 读取性能 | 适合全文检索、聚合分析 | 适合主键查询、范围查询 |
| schema 变更成本 | 无（自动） | 高（需 ALTER） |
| 内存消耗 | 较大（索引元数据） | 较小 |
| 数据一致性 | 弱一致 | 强一致 |
| 横向扩展性 | 强 | 中等 |
结论：
ES 的自动 mapping 提供了极高的写入灵活性，但代价是索引元数据膨胀、内存占用高、类型错误风险大。
MySQL 的 schema 则更适合结构化、高一致性业务。
| 场景 | 建议 |
|---|---|
| 日志、监控、埋点 | ✅ 开启自动 mapping（dynamic=true） |
| 搜索引擎、用户画像 | ✅ 自动 mapping + 动态模板 |
| 电商订单、金融账务 | ❌ 手动 mapping（dynamic=strict） |
| 混合型数据（部分稳定、部分动态） | ⚙️ 手动定义核心字段 + 动态模板控制扩展字段 |
| MySQL → ES 同步 | 🚫 禁止自动 mapping，使用 Logstash/ETL 生成预定义 mapping |
| 维度 | Elasticsearch 自动 Mapping | MySQL Schema |
|---|---|---|
| 定义方式 | 自动推断 | 手动定义 |
| 灵活性 | 极高 | 低 |
| 一致性 | 弱 | 强 |
| 修改成本 | 低（但错误代价高） | 高（但可控） |
| 可维护性 | 中等（需监控 mapping 爆炸） | 高 |
| 适用场景 | 搜索、日志、非结构化数据 | 交易、财务、结构化数据 |
Elasticsearch 的自动 mapping 是一把双刃剑：
它让数据“随写随用”，带来极大的灵活性；
但同时，也可能在规模化阶段埋下类型混乱、性能下降的隐患。
最佳实践是在项目早期利用其灵活性快速构建原型；
而在生产阶段，结合手动 mapping 与动态模板，建立“半自动、可控”的数据模型。
真正成熟的 ES 使用者，从来不会完全依赖自动 mapping。
自动化是起点，不是终点；灵活性需要以控制为前提。
这篇文章我们就专门讲清楚 refresh（刷新） 这一环节。它是 ES 写入流程的关键节点，既影响了数据什么时候能被搜索到，也影响了整个系统的写入性能和稳定性。
刷新 (refresh) = 把 内存 buffer 里的数据写到新的 segment 文件（先进入 OS cache），然后让它们对搜索可见。
刷新时间 (refresh interval) = ES 自动触发 refresh 的周期。
换句话说，refresh 的目标不是“数据持久化”，而是“数据可见”。也就是说，数据写进来之后，先保存在内存 buffer 里，这时候你去搜索是查不到的；一旦发生了 refresh，这些数据就会生成一个新的 Lucene segment，被索引打开，立即可搜索。
Lucene 是一个基于 segment 的倒排索引系统。segment 文件是 只读的，所以每次有新文档进来，都要生成新的 segment。refresh 就是触发这个生成过程的机制。
如果没有 refresh，你写入的数据永远停留在 buffer 里，不会变成 segment，自然也就查不到。
默认情况下，ES 的 refresh_interval 是 1s。也就是说，ES 每秒会自动刷新一次，所以新写入的数据通常 1 秒内就能查到。
我们可以通过 _settings API 来查看：
1 | # 查看某个索引的 refresh_interval |
返回结果示例：
1 | { |
这说明 my_index 索引的刷新间隔是 1 秒。
如果你刚写入一条文档，立刻查询可能查不到，但只要等 1 秒钟，它就会出现在搜索结果里。这个“近实时（Near Real Time, NRT）”特性，就是 ES 的核心设计。
在不同场景下，1 秒钟的 refresh_interval 并不是最优的。有时候我们希望更快可见，有时候则希望尽量少刷新，以提高写入性能。ES 允许你动态修改刷新间隔。
1 | # 设置为 30s（减少频繁刷新，写入性能更高） |
30s：表示 30 秒刷新一次。适合日志类场景，写多查少，降低频繁小 segment 的生成。-1：表示完全禁用自动 refresh，只能通过手动 _refresh 让数据可见。这个模式常见于 大批量数据导入。
"1s"：默认值，平衡写入和查询，适合绝大多数通用场景。"30s" 或更大：适合日志/监控场景，写多查少，减少小 segment 生成，提高写入吞吐。"-1"：禁用自动刷新，通常用于大规模初始化导入数据。导入完成后，手动 refresh，再改回默认值。理解 refresh_interval 的性能影响非常重要。
时间越短（比如 500ms、1s）
时间越长（比如 30s、60s）
禁用自动 refresh
1s。30s 或 60s，甚至更长。-1，导入后手动 refresh，再恢复 1s。这种调优思路能够兼顾写入性能和搜索体验。
| refresh_interval | 数据可见性 | 写入性能 | 典型场景 |
|---|---|---|---|
1s (默认) | ~1s 可查 | 中等 | 电商搜索、通用场景 |
30s | ~30s 可查 | 较高 | 日志、监控 |
-1 | 手动可查 | 最高 | 大规模数据导入 |
在写入 API 里，还可以通过 refresh 参数控制是否立刻刷新：
refresh=false（默认）
refresh=true
我们能够看到，即使 index_b 前面设置了”refresh_interval”: “-1”，再手动 refresh 之后也能够查找到了。
refresh=wait_for
"refresh_interval": "-1"，那么 wait_for 会一直卡住不返回，这时候最好手动 refresh。
在 Easysearch 里，手动刷新索引 就是调用 _refresh API。
这个操作会立刻把 内存 buffer 里的数据写到新的 segment（进入 OS cache），并让它们对搜索可见。
1 | # 刷新单个索引 |
使用场景：
⚠️ 注意：频繁手动 refresh 会导致大量小 segment，性能很差。生产环境中要谨慎使用。
为了更直观理解，我们看下 ES 写入生命周期：
1 | 时间轴 → |
refresh_interval=-1。_bulk 批量导入数据。POST /my_index/_refresh。refresh_interval=1s（或业务需要的值）。这样能显著提升导入性能，同时保证导入完成后数据立即可见。
1s，意味着 ES 是一个“近实时”系统。理解 refresh，不仅能帮助你解决“为什么数据查不到”的问题，还能让你在性能和实时性之间做出合理的权衡。
]]>折腾了一上午，我从安装依赖、加载服务、设备配对到最终的音频播放，完整走通了流程。过程中踩了几个典型的坑，把命令总结下来，甚至进一步改造成一个家庭“蓝牙音频中心”。
懒猫微服本质上就是一台 Linux 设备，可以在 neofetch 中查看系统信息。所以蓝牙相关的配置流程和常见的 Ubuntu/Debian 系统基本一致。只要我们搞定了蓝牙协议栈、音频服务和配对，就能让它像 PC 一样推送音频到蓝牙音箱。
懒猫微服没有提供 GUI 桌面环境，所以所有的这些步骤都得通过命令行完成。
首先安装系统缺少的几个依赖包：
1 | sudo apt install bluez bluez-tools pulseaudio-module-bluetooth libspa-0.2-bluetooth |
这里有几个关键点：
bluetoothctl 就靠它。1 | sudo systemctl restart bluetooth |
蓝牙服务在驱动加载、硬件唤醒等场景下，偶尔会出现异常，导致设备不可见。重启服务能有效避免 无法扫描设备、连接超时 等问题。
如果遇到
No default controller available的错误，可以通过systemctl status bluetooth检查蓝牙守护进程是否正常运行。
进入蓝牙控制台：
1 | bluetoothctl |
核心工具是 bluetoothctl。进入交互模式后，依次执行：
1 | power on |
逐条解释一下：
pair 时可能会报 “No agent available”。XX:XX:XX:XX:XX:XX 的 MAC 地址和设备名。Connection successful。我使用的是纽曼的蓝牙音箱，蓝牙控制台的输出大概是这样的：
当出现“成功配对并已连接”时，说明音频链路已建立。
安装轻量级播放器：
1 | sudo apt install mpg123 |
执行播放：
1 | mpg123 hello_tuya.mp3 |
运行时终端显示：
1 | (base) lzcbox-029c588e ~ # mpg123 hello_tuya.mp3 |
这时候音箱就能播放我们加载的 MP3 文件了。
最终可以整理成如下最小命令集：
1 | # 1. 安装依赖 |
连接失败（br-connection-page-timeout）
有时候会报类似：
1 | Failed to connect: org.bluez.Error.Failed br-connection-page-timeout |
这个大概率是音箱没进入配对模式，或者离设备太远。解决方法就是：重置音箱 → 靠近设备 → 再连。
开机自启
懒猫微服重启后可能蓝牙 sink 不会自动挂载，你需要写个 systemd 服务，启动时执行 bluetoothctl connect <MAC>。
容器化方案
如果想更整洁，可以拉个容器专门跑音乐服务，把 mp3 拉进去播放，或者跑个 MPD（Music Player Daemon）+ ncmpcpp。这样甚至可以做一个“云端点歌机”。
其实做到这一步后，懒猫微服就具备了一个“音频推送中转站”的能力。未来可以玩出很多花样：
mpg123 http://... 直接播放网络电台。懒猫微服虽然定位是轻量 NAS/微服务平台，但它的硬件能力其实远比我们想象的要强。今天这一折腾，我把它变成了一个“小型蓝牙音频播放器”。这种玩法对技术宅来说挺有意思：你既能学到 Linux 蓝牙栈和音频服务的原理，又能把手头的小盒子改造成一个实用的设备。
]]>那么，有没有可能在不安装客户端的情况下，也能直接通过浏览器访问到懒猫微服的内容？
这篇文章就是我折腾出来的一个解决方案：通过代理的方式，把原本只能在客户端访问的资源，转化为“浏览器可直达”的体验。下面我会一步步展开。
这个灵感并不是凭空出现的，而是源自我之前的工作经历。那时，公司网络屏蔽了维基百科，导致很多查资料的场景非常不方便。解决方案就是通过配置特定的 HTTP 代理，把流量转发出去，从而实现访问被封锁的网站。
在那个时期，我经常需要和公司的 IT 的同事沟通这些事情。这段经历让我意识到，代理其实就是一种“流量搬运工”。它不需要改变服务本身，而是通过“转发”让原本不可达的资源变得可达。
于是我就想：能不能借助代理，把访问懒猫微服的流量“搬运”出来，从而绕过必须安装客户端的限制？
我们可以把这个问题抽象成一个三方交互的模型：
通常情况下，A 是无法直接访问 C 的，因为懒猫微服要求使用它的 APP 来做身份校验。
但如果我在 B 上部署一个代理，让 A 的请求先走 B，再由 B 转发到 C，那么 A 就能“曲线救国”。
这种思路其实就是“中转站”模型：
这就是代理的核心魅力：用最小的改动，让本来不兼容的系统实现互通。
我主要尝试了两种代理思路，每一种都有各自的适用场景：
透明代理的原理是：把客户端的默认网关改成代理服务器的地址，让所有流量都先经过代理，然后再由代理进行转发。
HTTP 代理则更直观：直接在客户端的网络设置里，配置一个 HTTP 代理（IP + 端口），所有浏览器流量就会走这个代理。
我最终选择了 HTTP 代理方案。操作过程很简单：
heiyu.space 域名。结果很惊喜：在没有代理之前，这个域名是打不开的；在配置了代理之后，页面顺利加载了。
这意味着，即便没有安装懒猫微服 APP，也能直接通过浏览器访问资源。
如果采用透明代理，操作方式是：在 iPad 的网络设置里，把默认网关改为代理机器的内网 IP。实际效果展示
从截图中可以看到我本地没有安装猫微服客户端，如果不配置网关的这种情况回无法访问 heiyu.space，浏览器报错。
配置好跳板机之后，懒猫微服的启动器页面顺利加载。
甚至可以进到我的面食比例计算机，里面的内容直接用浏览器访问。
这种方案在日常生活中非常有用：
以前分享文件给朋友，还是觉得流程太重：下载 APP、注册账号、登录，再操作一堆。现在，我只要这样一个流量转发，就能把分享变成真正的一件小事——点开链接，直接下载。
这才是我想要的体验：技术改变生活。
]]>Easysearch 本质上是一个搜索引擎数据库，是 Elasticsearch 的国产化替代方案。它在大多数情况下被部署在 x86_64/arm 架构的服务器上，搭配 SSD 或 NVMe 作为存储，用来做全文检索、大规模日志分析或向量搜索。在常规的生产场景中，我们很少会把它和“嵌入式开发板”联想在一起。毕竟，后者 CPU 性能有限、内存紧张、存储设备大多是 eMMC 或低速 SD 卡，看起来完全不是数据库的适配环境。
不过，学习和实验的环境往往不需要极致的性能。于是，我决定尝试一下，把 Easysearch 移植到泰山派上跑起来。
由于我的开发板连接 Dockerhub 经常超时， 而我的 MacOS 有之前缓存的 Docker 镜像。我的第一步是把镜像在 Mac 上先导出。
1 | docker save -o easysearch-1.15.0.tar infinilabs/easysearch:1.15.0 |
上面这条命令会把名为 infinilabs/easysearch:1.15.0 的镜像打包成一个 tar 文件，文件大小大概 700MB 左右。导出的好处是：我不需要在嵌入式开发板上重新去拉取 Docker Hub 镜像（速度慢且容易失败），只需要把 tar 包通过 FTP 或者 SFTP 上传过去即可。
由于泰山派跑的是一个裁剪过的 Linux 系统，自带 SSH 和 FTP 服务，所以我直接用 FTP 客户端把 easysearch-1.15.0.tar 上传到板子的 /home 目录。上传速度受限于板载 eMMC，大概 3MB/s 左右，耐心等一会儿就好。
上传完毕后，我用 SSH 登录到开发板。
进入板子后，第一件事情就是把镜像导入到本地 Docker：
1 | docker load -i easysearch-1.15.0.tar |
等待几分钟，Docker 会把镜像重新解压并注册到本地。由于板子 CPU 性能有限，这个步骤比在笔记本上要慢不少，但最终会看到 familiar 的镜像 ID 出现在 docker images 的列表中。
接下来要注意的就是一个经典坑：Easysearch/Elasticsearch 类的数据库要求内核参数 vm.max_map_count 至少设置为 262144，否则启动会直接报错。
1 | sudo sysctl -w vm.max_map_count=262144 |
这条命令会临时修改内核参数。如果你打算长期使用，可以把它写到 /etc/sysctl.conf 或者 /etc/sysctl.d/ 里。
有了镜像和内核参数，接下来就是熟悉的 docker run 了：
1 | docker run --name easysearch \ |
第一次启动时，容器会打印出初始的超级管理员密码，可以在日志里找到。
容器启动后，在浏览器访问开发板的 IP 地址的 9200 端口，就能打开 Easysearch 的自带管理 UI。
UI 上显示，除了内存很快被吃满之外，其他方面表现完全可用。毕竟 Easysearch 默认会尝试尽可能缓存索引数据，而 RK3566 开发板通常只有 2GB 或 4GB 内存，溢出是难免的。但从查询速度和索引写入的小规模实验来看，性能并没有想象中那么糟糕。我尝试运行了一些 DSL，也没有什么问题。
换句话说，虽然这套组合是 arm CPU + eMMC 存储，但作为学习和体验之用已经足够。
为了更直观地观察运行情况，我在容器启动后打开 htop。
可以看到 Easysearch 启动初始化时 CPU 占用飙升，内存使用量也接近物理上限。但在完成索引加载后，CPU 占用下降明显，保持在个位数到十几的水平。
这说明在嵌入式环境下跑数据库的瓶颈更多是 初始化 和 大规模数据处理，而不是日常的小规模查询。对于个人实验、API 测试和功能熟悉，完全可以胜任。
把 Easysearch 部署在 RK3566 这样的小板子上，意义主要有两个：
当然，它也有明显的局限：
这次尝试算是一次“异想天开”的实验：把 Easysearch 从 PC 搬到了一块嵌入式开发板上。最终结果是——它真的能跑，而且还比预想的顺畅。除了内存不足和初始化速度慢，实际使用体验完全能满足学习场景。
如果你平时不想让笔记本长时间开着数据库，又恰好手边有一块开发板，那么完全可以用类似的办法，把 Easysearch 跑在开发板上作为一台“轻量数据库机”。
一句话总结： Easysearch 其实没有你想象中那么“重”，只要底层 Linux 和 Docker 能跑，它就能跑。
]]>其实我对这个设备的期待已经很久了。过去一年里，AI 大模型的爆发几乎让每个技术人都产生过同一个念头：能不能有一台属于自己的“算力仓”？不用再排队租云 GPU，不用担心账单像无底洞一样增长，更不用把敏感数据传到云端。所以赶了个首发，等了两天拿到了商品。
懒猫 AI 算力仓的核心是 NVIDIA Jetson AGX Orin。
这块板子可能很多人都听过，它本来的定位是“边缘计算”和“机器人中枢”，算是英伟达给嵌入式 AI 场景设计的亲儿子产品。比如跑 YOLO 目标检测、机械臂控制，这些都是它的常见场景。
除此之外， Orin 还有一个优势，就是 完整继承 CUDA 生态。这就意味着，它和桌面 GPU 一样，能跑主流大模型和 AI 框架。相比之下，很多国产芯片虽然跑分也许很高，但因为缺乏 CUDA 生态，真正落地的时候往往要做大量适配工作。可能你下载了模型，但能不能跑起来就是另一个问题了。
CUDA = 生态优势。
这点在 AI 时代非常关键。使用懒猫 AI 算力仓，下载完模型就能马上测试，而非 CUDA 芯片用户，可能还要花上几个月适配环境。这就是差距。
所以当懒猫把 Orin 改造成家用级的 AI 算力仓时，我的第一反应就是：这玩意儿正好补上了家里缺的那块“私有超算”拼图。
包装比我预想的更精美，拆开的时候甚至有点“科幻感”。外观是简洁的机身，棱角分明，风格上有点像星球大战里的装置。
尽管实物拿着沉甸甸的，但尺寸比我想象的还要小一些，高度大约只有懒猫微服的 NAS 一半。拿在手里的重量也不到 1300 克，比 MacBook Pro 还要轻很多，所以理论上你带出门也不是不行（不是）。
这种“袖珍 + 全固态”的组合，第一观感就是结实耐用，而且空间利用率极高。塞进机柜里刚刚好。
接下来看看核心参数：
这套组合，基本就决定了它能直接运行 70B 参数级别的大模型，而且是真正意义上的“无限 Tokens”，不像云端那样有额度限制。
在存储扩展方面：
接口配置也很周到：
官方参数写着整机功耗 64W，所以很省电。要知道，一块台式机的 4090 往往就能拉到 400W，而 Orin 的 64W 几乎可以说是“节能怪兽”。我把一个小型工作站，直接塞进了我的机柜里。
这次买算力仓，还有一个重要原因：我家里已经在用懒猫微服的生态。算力仓一接入，就能和原来的设备形成闭环。
比如：
这种组合让我感觉像是给自己搭了一个“家用 AI 实验室”。来一张和机柜里其他设备的合影 ↓
懒猫算力仓的应用场景非常多：
整体来说，懒猫 AI 算力仓给我的感觉就是：
如果说之前还在犹豫“要不要上云 GPU”，现在真的可以考虑直接在家里搞一台 Orin 算力仓。算力、省钱、数据安全，全部兼顾。
更重要的是，这不是一台冰冷的机器，而是让我随时能打开 AI 世界大门的“钥匙”。
]]>算力仓从硬件层面来说就是一台高性能的小型 AI 算力设备，但如果只是孤立地插上网线、运行系统，它就像一台“裸机”，并不能和我们常用的软件生态融合。懒猫微服作为一个容器化的应用生态，本身聚合了丰富的 AI 应用、插件和社区资源。把算力仓绑定到微服，就意味着你不仅能在局域网内访问算力，还能直接调用它的 API 来支撑各类应用。
比如：
一句话总结：绑定就是打通生态，让算力仓成为微服体系中的“外挂显卡”。没有绑定，它只是一个单机的开发板；绑定之后，它才真正融入到懒猫微服的生态网络里。
绑定流程的第一步是安装懒猫 AI 浏览器。这款浏览器是懒猫微服官方推出的专用入口，它在 Chromium 的基础上去除了 Google 的追踪代码，主打隐私和轻量。同时，它内置了算力仓插件，可以让浏览器与算力仓直接通信。
很多人可能会问：“为什么一定要用它？我能不能直接用 Chrome 或 Edge？”答案是理论上可以，但官方推荐 AI 浏览器，是因为它不仅省去了自己安装插件的步骤，还能确保和算力仓的兼容性。尤其是对小白用户而言，开箱即用的体验比手动安装插件要友好得多。
安装完成后，浏览器会自动跳转到 https://ai.<name>.heiyu.space/ 这个地址。这其实是一个专门的配置门户，我们后续的绑定操作就是在这里完成的。
如果你使用的不是 AI 浏览器，也没关系。官方同样提供了独立的插件下载入口：
1 | https://extensions-ai.<name>.heiyu.space/ |
在这里下载安装后，效果和 AI 浏览器自带插件是完全一致的。区别只在于操作步骤多了一点点，但对于喜欢用主力浏览器的人来说，这个方式会更灵活。
插件的核心作用，就是在网页端注入算力仓的能力。比如，你在 Google 搜索页面时，可以直接点击总结按钮，让算力仓帮你对搜索结果做归纳。这一刻，你就能直观感受到“本地 AI 算力”与日常浏览体验结合的爽感。
当浏览器启动并加载插件后，在右上角点击设置按钮，就能看到绑定算力仓的入口。界面非常简洁，主要就是一个“添加算力仓”的流程。
这里需要注意，绑定并不是直接输入算力仓的 IP，而是先让微服客户端与算力仓建立信任关系。换句话说，微服扮演的是“中介人”的角色，它负责把应用和算力仓之间的调用关系建立起来。这样设计的好处是：用户不需要关心底层 API 地址，只需要点几下就能完成对接。
绑定算力仓之前，你需要先启动本地的懒猫微服客户端。在客户端里输入你的微服名称，然后等待连接成功。
这一环节是整个流程的关键：只有当微服客户端处于运行状态时，它才能帮你发现微服和算力仓。算力仓和微服的关系，就像 NAS 和群晖套件一样，必须要有一个“宿主环境”来承载它。
当微服和客户端连接成功后，你会在界面里看到“添加算力仓”的按钮。点击之后，微服就会开始在局域网内扫描设备。
这里有一个细节体验：只要算力仓接上网线，就能被自动发现。猜测它通过 mDNS/Bonjour 的方式在局域网广播，客户端自然就能识别出来。对比市面上一些设备需要手动输入 IP 或者搞复杂的端口映射，懒猫算力仓的体验确实要顺滑很多。
值得一提的是，算力仓的设计允许你绑定多台设备。如果你财力雄厚，可以一次性接入多个算力仓，微服会自动帮你做任务分配。这意味着什么？意味着你可以搭建一个“家庭 AI 超算集群”。对于 AI 极客来说，这是一个非常诱人的玩法。
扫描到算力仓之后，在设备的背面你会看到一个“M”按键。只要按下它，就能完成和微服的配对。
为什么需要这一步？因为这是设备级的安全认证。只有物理触发了 M 键，微服才会确认你是设备的真实拥有者，避免别人通过网络把你的算力仓“偷走”。
按下之后，你会在客户端看到“配对成功”的提示，这意味着你的算力仓正式加入到了微服生态。
绑定完成后，你会在微服的设置页面里看到算力仓的选项。此时，你就可以选择不同的模型来运行对应功能。
比如：
这一切，都是通过一个简洁的界面完成的，几乎不需要你去敲命令。
绑定成功的第一个直观体验，就是在 Google 首页上使用总结功能。以前你可能需要安装第三方插件，或者把内容复制到 ChatGPT 界面里再问，现在直接在浏览器里点一下按钮，就能调用本地算力仓来生成总结。
更重要的是，这个总结是本地推理完成的，你的数据不会上传到外部云端。这对于关心隐私的人来说，是一个巨大的优势。
整个绑定流程下来，我最大的感受有三点：
在我看来，懒猫算力仓和懒猫微服的结合，是一次“硬件 + 软件生态”的双重升级。前者提供了扎实的算力基础，后者则给了它用武之地。两者结合之后，才算真正完成了从设备到应用的闭环。
未来我会继续分享在算力仓上部署不同 AI 应用的体验，看看它在文本生成、图像处理、甚至视频推理等场景中的表现。敬请期待《懒猫算力仓初探（三）：如何 SSH 登陆以及配置免密 sudo？》。
]]>懒猫算力仓启动后，我们可以通过 SSH 来进行远程管理。设备出厂时已默认开启 SSH 服务端，所以我们要做的第一步是获取它的 IP 地址。
如果你使用路由器，可以在路由器后台查看分配到的 IP，并用 telnet ip地址 测试端口是否开放：
如果外接了显示器，也可以直接在终端执行：
1 | ip addr |
懒猫算力仓的默认用户名和密码都是 nvidia，所以我们可以直接尝试登录：
1 | ssh nvidia@192.168.1.100 |
首次登录会提示是否接受 fingerprint，输入 yes 即可。
每次输入密码太麻烦，可以配置免密登录。
在本地生成 SSH 密钥（如果还没有）：
1 | ssh-keygen -t rsa -b 4096 |
一路回车，默认生成在 ~/.ssh/id_rsa 和 ~/.ssh/id_rsa.pub。
将公钥拷贝到目标机：
1 | ssh-copy-id nvidia@192.168.1.100 |
如果目标机没有 ssh-copy-id，可以手动追加：
1 | cat ~/.ssh/id_rsa.pub | ssh nvidia@192.168.1.100 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" |
以后只需执行：
1 | ssh nvidia@192.168.1.100 |
就能直接登录而无需密码。
~/.ssh/config 简化命令如果你经常要连同一台设备，可以在本机配置 SSH 简化命令。
编辑：
1 | vim ~/.ssh/config |
添加配置：
1 | Host orin |
保存后，就可以直接：
1 | ssh orin |
配合免密登录，体验更流畅。
Ubuntu 上免密 sudo 有两种方式：
进入算力仓：
1 | sudo vim /etc/sudoers |
找到：
1 | root ALL=(ALL:ALL) ALL |
在下面新增：
1 | nvidia ALL=(ALL:ALL) NOPASSWD:ALL |
保存退出即可。
这样不会污染原始配置，更安全：
1 | echo "nvidia ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/nvidia |
尝试免密 SSH 登录。
登录后执行：
1 | sudo ls /root |
如果无需输入密码，说明免密 sudo 已生效。
如果 SSH 无法登录，可以按“本地 → 网络 → 服务端 → 配置”逐步排查：
用户名、IP 是否正确：
1 | ssh user@192.168.1.100 |
如果端口改过，需显式指定：
1 | ssh -p 2222 user@192.168.1.100 |
测试连通性：
1 | ping 192.168.1.100 |
确认端口是否开放：
1 | telnet 192.168.1.100 22 |
确认 SSH 服务是否运行：
1 | sudo systemctl status ssh # Ubuntu/Debian |
若未运行，启动并设置开机自启：
1 | sudo systemctl enable ssh --now |
Ubuntu:
1 | sudo ufw status |
CentOS/RHEL:
1 | sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload |
检查：
1 | sudo nano /etc/ssh/sshd_config |
关键项：
1 | Port 22 |
修改后重启：
1 | sudo systemctl restart ssh |
Ubuntu：
1 | sudo tail -f /var/log/auth.log |
CentOS：
1 | sudo tail -f /var/log/secure |
确保 .ssh 目录和文件权限正确：
1 | chmod 700 ~/.ssh |
通过本文的步骤，我们完成了以下几件事：
这样配置下来，你就能在懒猫算力仓上实现“一步登录 → 直接 sudo”的丝滑体验。无论是本地调试模型，还是在局域网中远程部署服务，你都能做到“一条命令直达 root 权限”。这让懒猫算力仓真正变成了一个可以随时掌控的 AI 算力伙伴
]]>很多新手刚上手算力仓时，都会遇到类似问题：
其实完全不用担心。虽然算力仓的核心是 NVIDIA Jetson AGX Orin 开发板，但它运行的系统本质上是一个 Linux 发行版（Ubuntu 22.04）。因此，大多数 Linux 服务器的文件传输方法，都可以无缝应用到懒猫 AI 算力仓上。
本文将从 命令行工具、图形化工具、高效同步、临时传输 和 云同步 五个方面，详细介绍客户端如何与懒猫 AI 算力仓进行文件传输，帮助你构建一个高效、稳定的工作流。
在传文件之前，首先要确认两件事：算力仓的 IP 地址， ssh 服务运行状态。
1 | ip addr show |
找到类似 192.168.x.x 的地址即可。
建议：为避免每次重启导致 IP 变化，可以在路由器中绑定 固定 IP。
懒猫 AI 算力仓默认预装了 OpenSSH 服务，因此只要知道用户名和密码，就能远程登录和传输文件。
nvidianvidia当然，更推荐配置 SSH Key 免密登录，更安全也更高效。具体配置可以参考这篇文章：算力仓 SSH 免密配置教程。
SCP（Secure Copy Protocol） 是 Linux/Unix 世界中最常见的文件传输方式，基于 SSH 加密，操作简单。
上传文件到算力仓
1 | scp file.txt nvidia@192.168.x.x:~ |
从算力仓下载文件到客户端
1 | scp nvidia@192.168.x.x:~/1.txt . |
上传整个目录
1 | scp -r ./localdir nvidia@192.168.5.50:/home/nvidia/ |
SCP 的优点是 原生支持、无需额外安装，适合偶尔传输单个文件或小目录；缺点是大文件速度一般，且不支持断点续传。
SFTP（SSH File Transfer Protocol） 同样基于 SSH，但它支持交互式操作，功能更丰富。
1 | sftp nvidia@192.168.5.50 |
如果你不喜欢命令行，可以选择图形化工具：
参考文章：FileZilla 连接算力仓。
适用场景：SFTP 非常适合需要频繁上传/下载小文件的用户，尤其是习惯拖拽操作的开发者。
如果你需要频繁同步数据集、模型权重或代码目录，rsync 是比 SCP 更高效的工具。
上传目录
1 | rsync -avz ./localdir/ nvidia@192.168.x.x:/home/nvidia/remote-dir |
下载目录
1 | rsync -avz nvidia@192.168.x.x:/home/nvidia/remote-dir ./localdir/ |
断点续传大文件
1 | rsync -avz --partial --progress largefile.tar nvidia@192.168.x.x:/home/nvidia/ |
例如，如果你在本地不断修改代码仓库，rsync 能快速同步更新的部分，而无需重新传输整个目录。
有时候你只是想传一个临时文件，不想折腾 SSH，这时可以用 HTTP 服务 或 curl。
1 | cd ~/myfiles |
在算力仓浏览器中访问：
1 | http://192.168.x.x:8000/ |
在算力仓终端使用如下命令即可下载文件。
1 | curl -O http://192.168.x.x:8000/target_file.txt |
还可以显示进度条：
1 | curl -# -O http://192.168.x.x:8000/large_file.iso |
或指定保存路径：
1 | curl -o /path/to/save/file.txt http://192.168.x.x:8000/file.txt |
适用场景：临时传小文件时非常好用，几乎不需要额外配置。
因为算力仓有 GUI 桌面，所以可以当作 PC 来用，如果你在笔记本和算力仓之间频繁切换，可以考虑 云同步工具。
使用经验：我个人推荐 Syncthing + Git 的组合。Syncthing 用来自动同步数据和配置文件，而 Git 用来管理代码版本。这样既能保证文件实时更新，又能避免版本混乱。
常见场景下的最佳选择：
scpSFTP + WinSCP/FileZillarsync对大多数懒猫 AI 算力仓用户来说，SCP + rsync 足以满足日常需求。如果你希望构建更稳定的工作流，可以结合 云盘/同步工具，让文件管理更加自动化。
懒猫 AI 算力仓不仅仅是一台小型 AI 超算，它同时也是一个灵活的 Linux 工作站。掌握不同的文件传输方式，能让你在写代码、跑实验、部署服务时更加高效。
scp 就足够。未来，当你完全把算力仓融入到工作流时，它就不仅是一个推理/训练机器，而是真正的 远程 AI 工作站。
掌握好文件传输的方法，你会发现：懒猫 AI 算力仓不仅提供算力，更能成为你日常开发中的最佳助手。
]]>本篇文章将详细讲解如何在算力仓桌面环境中，通过图形化方式（GUI）配置静态 IP 地址，并对比命令行 nmtui 的方法，让你的算力仓网络配置更稳、更容易管理。
算力仓不像懒猫微服那样自带域名访问功能。
如果我们希望通过 SSH、VSCode 或 API 服务长期远程访问它，就必须让它的 IP 地址保持不变。否则，一旦 DHCP 动态分配的地址发生变化（比如重启路由器后），所有外部访问都会中断。
因此，静态 IP 是算力仓稳定访问的关键配置之一。
在「关于本机」中可以看到，算力仓运行的是 Ubuntu 22.04 LTS 桌面版。这意味着我们无需编辑配置文件或敲命令，而是可以直接通过系统设置进行网络管理。
右上角的系统托盘里有一个网络图标（有线网络是双箭头，Wi-Fi 是扇形波纹），这就是进入网络设置的入口。
在 Ubuntu 桌面下，图形界面的背后其实就是 NetworkManager 服务，也就是我们在服务器端使用 nmtui 或 nmcli 命令操作的同一个核心组件。
下面我们一步步完成整个配置流程，从打开设置到验证网络。
点击右上角网络图标 → 选择「设置」或「Network」。
也可以在左下角应用菜单中搜索「Settings」，在左侧栏中选择「网络（Network）」。
进入后，你会看到两种网络接口：
如果算力仓通过网线连接局域网，就选择有线网络进行配置。
在「有线网络」一栏中，找到当前正在使用的接口（如 _Wired connection 1_），点击右侧的齿轮 ⚙️ 图标。
这个配置界面对应的是 NetworkManager 的“连接配置文件”。
每一个物理接口都有自己的配置文件，保存 IP、DNS、网关等信息。
切换到 IPv4 标签页，可以看到「方法（Method）」下拉菜单：
默认是「自动（DHCP）」，我们需要改为「手动（Manual）」。
修改后，会出现以下字段：
| 字段 | 示例值 | 说明 |
|---|---|---|
| 地址（Address） | 192.168.1.100 | 设备的固定 IP |
| 子网掩码（Netmask） | 255.255.255.0 或 /24 | 家用路由器一般为 /24 |
| 网关（Gateway） | 192.168.1.1 | 通常是路由器的地址 |
| DNS | 8.8.8.8, 1.1.1.1 | 推荐填写 Google 与 Cloudflare 的 DNS |
注意：
IP 地址必须是未被占用的。可以先用命令测试：
1 | ping 192.168.1.100 |
若返回 “Destination Host Unreachable”，说明该 IP 可用。
填写完成后，点击右下角的「Apply」或「Save」。
接着关闭再开启一次该网络接口，让配置立即生效。
（很多人忘记这步，导致 IP 没有更新。）
打开终端（Ctrl + Alt + T），输入：
1 | ifconfig |
确认你的新 IP 已生效后，测试外网连通性：
1 | ping 8.8.8.8 |
若返回类似：
1 | 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=30.5 ms |
说明静态 IP 设置成功。
静态 IP 设置完成后，你就可以在懒猫微服上用端口转发工具，将算力仓的 SSH 服务暴露到微服域名下。
例如，通过微服域名的某个端口就能直接 SSH 登录算力仓，实现两端联动：
之前我们在懒猫微服上使用过 nmtui 命令配置静态 IP。
其实两种方法底层一致，都是操作 NetworkManager。
| 对比项 | 图形界面设置 | nmtui 命令行设置 |
|---|---|---|
| 适合用户 | 新手、喜欢可视化操作 | 熟悉终端的高级用户 |
| 可视化程度 | 界面直观 | 字符交互 |
| 误操作风险 | 低 | 较高 |
| 生效方式 | 即时生效 | 需手动保存 |
| 使用场景 | 桌面系统（算力仓） | 无图形环境（微服） |
一句话总结：
算力仓有桌面，用图形界面；
微服是服务器，用命令行。
两者都基于同一个 NetworkManager，稳定、可靠又高效。
通过图形界面设置静态 IP 的优点：
推荐实践：
nmtui]]>懒猫微服靠命令行，算力仓靠图形界面。
底层同源，体验不同，效果一样稳。
/_ui 路径，就能直接进入可视化页面。
登录后，首页就能看到集群的核心监控信息，包括节点数量、分片分布和索引情况。
默认面板已经内置了常用指标：节点、分片、索引级别的监控数据都能直接查看。
许多用户期盼已久的 字段存储图 也终于回归，让存储空间的使用情况一目了然。整体上，基本所需的监控指标都齐备了。
其实我最喜欢的功能是这个开发工具，这样在部署集群之后就可以很容易的写 DSL 语句来执行来。不需要调用 REST API 或者暗转跟其他工具，Easysearch 部署好之后，所见即所得。
这意味着集群部署完成后，你就能立刻：
这种“所见即所得”的体验，大大提升了调试和使用的效率。
除了监控和开发工具，界面中还集成了 别名管理 和 索引模板 功能。该有的功能差不多都有了。
这让日常配置和维护变得更加直观，无需频繁在命令行和 JSON 文件之间来回切换。
这次更新，可以说是把一个“微缩版 Console”直接集成进了 Easysearch 内部：
对于开发者和运维人员来说，这无疑让 Easysearch 的使用更加高效、轻量化，真正实现了“安装即用”。
]]>如今，我们可以在 懒猫微服 的应用商店中一键部署 KSpeeder，并结合懒猫自带的 端口转发、内网穿透、可视化管理 等功能，使 Docker 镜像加速更加高效、易用和可维护。
在传统环境下，部署像 KSpeeder 这样的工具通常需要：
而在懒猫微服上，这些复杂步骤被大幅简化：
这使得 KSpeeder 不再是一个需要额外维护的独立工具，而是融入懒猫微服生态的“开箱即用”解决方案。
在懒猫微服的支持下，KSpeeder 能够提供以下关键能力：
特别感谢社区群友 Peterpig 的帮助，由于 KSpeeder 的限制，镜像源无法直接通过 ingress 暴露端口，因此这里使用了懒猫微服的 端口转发功能，保证服务可用。
在本地客户端上，将 registry.linkease.net 指向懒猫微服所在主机的 IP 地址：
1 | sudo vim /etc/hosts |
在文件最后一行添加：
1 | 192.168.x.x registry.linkease.net |
（例如：192.168.5.128 registry.linkease.net）
完成后刷新 DNS 缓存：
1 | sudo dscacheutil -flushcache |
通过 ping 验证是否生效：
1 | ping registry.linkease.net |
完成配置后，就可以直接通过 KSpeeder 加速源拉取镜像：
1 | docker pull registry.linkease.net:5443/image:tag |
我使用的是 Orbstack，可以在其配置文件中加入镜像加速源，让 Docker 默认通过懒猫微服上的 KSpeeder 服务：
1 | "registry-mirrors": ["https://registry.linkease.net:5443"] |
这样每次执行 docker pull 时，就无需手动添加前缀：
1 | docker pull nginx |
可以通过查看配置文件确认：
1 | cat ~/.orbstack/config/docker.json |
配置完成后，可以在懒猫微服的 Web 界面直观地查看镜像下载状态与速度。
实际测试表明，借助懒猫微服的 端口转发和可视化管理能力，KSpeeder 能够稳定高效地运行，显著缓解 Docker 镜像下载慢和中断的问题。
在频繁依赖 Docker 镜像的开发环境中，“KSpeeder + 懒猫微服” 是一个高效、稳定、可扩展的组合方案，值得推荐。
]]>看似解决了问题，但 Git 同步的体验并不好：多端同步时经常遇到冲突，每次写完笔记都要处理一堆合并，既麻烦又影响心情。这件事困扰了我很久。
直到后来入手了 懒猫微服，问题才彻底缓解，所以决定把这段折腾经历记录下来。
懒猫提供了基于 WebDAV 协议的网络存储，天然支持 Obsidian 的同步需求。它不像 Git 那么复杂，不需要 commit/push，也不会频繁出现冲突。只要配置一次，就能稳定、流畅地跑起来。
所以我把 Obsidian 笔记直接备份到懒猫微服。在网盘中可以看到 WebDAV 的域名、用户名和密码。懒猫微服的转发没有任何限制，443 端口也能直接使用。这样即使在外面，也能随时访问。
首先在 Obsidian 插件市场搜索并安装第三方插件 【Remotely Save】。
在【Remotely Save】中，选择 WebDAV 模式，然后输入服务器地址：【地址+端口+目录路径】。
我的地址是：
1 | https://file.name.heiyu.space/dav/ob_notes |
由于 /dav 是网盘的根目录，我新建了一个文件夹 ob_notes 来存放笔记，方便结构化管理。
输入懒猫微服提示的用户名和密码，鉴权方式保持 basic，然后检查服务器连接。如果目录不存在，就会在检查时报错。
我设置了 自动运行，并且每 10 分钟同步一次。毕竟是自己的微服，不存在 API 限制，也不用担心额外费用。更重要的是，我开启了 双向同步：
再也不用担心 Git 冲突，写完笔记就能安心同步。
这是我在网盘上的结果，保存的瞬间，笔记就自动完成同步：
写到这里，其实结论很简单：懒猫微服彻底解决了我在 Obsidian 上被 Git 同步折磨的痛点。相比频繁冲突的 Git，懒猫微服的 WebDAV 同步方式更简单、更稳定，还能随时随地使用。
如果你也在用 Obsidian，又还在为同步问题发愁，不妨果断试试懒猫微服——真正做到写完即同步，省心又安心。
一句话：Obsidian 最佳拍档，果断选懒猫微服。
]]>说干就干，从箱子里翻出一个硬盘盒，把拆下来的硬盘装进去，再用 Type-C 数据线插到懒猫微服后面的接口，立刻就能当作外接硬盘使用。
为了确认是否挂载成功，我在懒猫的终端输入了：
1 | df -TH |
输出结果如下：
1 | Filesystem Type Size Used Avail Use% Mounted on |
逐行解释一下：
/dev/sdb3 → 说明识别到的硬盘分区是 sdb3；fuseblk → 代表这是通过 FUSE 驱动挂载的块设备。大多数情况下，这就是 NTFS 文件系统，因为 Linux 自带的 NTFS 支持往往依赖 ntfs-3g 这样的 FUSE 驱动；/lzcsys/run/media/系统，懒猫系统会自动在 /media 下生成一个中文目录，名字就是 Windows 盘符的中文别名（比如“系统”）。也就是说，这块 Windows 硬盘已经被完整挂载，可以直接访问。
为了更清楚地看到硬盘的分区情况，我又执行了 lsblk：
1 | (base) lzcbox-029c588e ~ # lsblk |
从结果可以看出：
sdb1 → 300 MB，这个就是 EFI 启动分区。在 Windows 系统里，这个分区通常用来存放启动管理器、Boot Loader 等信息；sdb2 → 16 MB，这是 MSR（Microsoft Reserved）分区，Windows 在初始化 GPT 磁盘时会自动保留，用来为将来的系统更新留空间；sdb3 → 1.8 TB 主分区，真正存放用户数据的地方，现在已经被挂载到了 /lzcsys/run/media/系统。这套分区方案是 Windows 的标准 GPT 分区表结构。如果是 Linux，通常会看到 /boot、swap、/home 这样的挂载点。而 Windows 则用 EFI + MSR + 主分区的方式来管理。
知道分区后，下一步就是进入挂载目录 /lzcsys/run/media/系统。
里面的目录结构几乎和 Windows 下看到的一样，核心的就是 Users 文件夹。
例如：
1 | (base) lzcbox-029c588e ~ # ls /lzcsys/run/media/系统/Users |
在 MyUser 目录下，能找到 Desktop、Documents、Downloads、Pictures 等熟悉的文件夹。
这就是 Windows 用户的个人数据目录。只要进入对应的用户文件夹，就能直接把桌面文件、文档、照片、下载内容拷出来。
这里要注意：
Program Files）没必要去动，大部分个人数据都在 Users 目录下；更方便的一点是：懒猫微服不仅仅能在终端挂载，还能在自带的 网盘界面里直接显示这个外接硬盘。
我打开懒猫的 Web 网盘页面，果然多出了一个名为“系统”的磁盘目录。
点进去以后，就能直接看到原来 Windows 里的 Users 文件夹。
这意味着：
对于普通用户来说，这个功能基本上等于“即插即用”。坏掉的 Windows 硬盘，插上懒猫就能当网盘用。
整个过程体验下来，其实有点像“数据救援”。
一台电脑坏了，换做以前，大家可能要找专业修理店，或者买 制作 Windows PE 启动盘去折腾。
但有了懒猫微服，这件事变得非常简单：
从头到尾几乎不需要额外的软件，Linux 自带的 FUSE 驱动就能把 NTFS 分区挂上去。
即使完全不会 Linux 命令行，也能通过懒猫的网盘访问到文件。
“坏掉的 Windows 不要扔，插在懒猫上还能用。”
]]><机器名>.heiyu.space**。这就意味着，不管你是在内网还是外网，访问方式都是一致的——直接用域名即可。对习惯了公网/私网切换的我来说，这个设计一开始挺新奇，也忍不住想探索背后的机制和性能表现。于是就有了这篇文章：一次围绕 懒猫微服网络访问和测速表现的实战记录。
你可以使用 dig AAAA <机器名>.heiyu.space 来解析这个域名，背后是一个 IPV6 的地址。尝试破解了很久也没弄懂这个这个具体的转发机制，不过结论就是，不管你在内网还是互联网上访问这个域名都没问题。当然如果你内网有代理的话，流量很可能通过代理从外边转一圈再回来，这个需要手动改下规则。
先说结论，懒猫微服的无线网卡还是很好的。不过也遇到了在 UPS 附近出现严重干扰的情况。
<设备名>.heiyu.space为什么要把有线和无线 IP 分开说？因为逻辑上它和云服务器一样：用公网 IP 就是走公网，用私有 IP 就是走内网。
在 Linux 环境下，可以使用 iw wlp4s0 link 查看 WiFi 的连接情况：
1 | watch -n 1 iw wlp4s0 link |
如果提示 Not connected.，说明当前 WiFi 没有连接。
为了保证测试结果客观，我前后测试了很久，还顺带拿黑群晖做了对比。测试环境涵盖了 1G 和 2.5G 的场景，工具主要用了 iperf3 和 LibreSpeed。
不过在 2.5G 的小米路由器环境下，经常遇到抽风的情况，这点要单独吐槽一下。
有限可以跑满 1G，WIFI6 协商速率可以跑满 2401Mbps。
基本也是 WIFI6 协商满速 2401Mbps
使用 IP 测速度
1 | [ ID] Interval Transfer Bitrate |
基本稳定在 940Mbps 左右。
可以看到这里已经是协商到了 2500Mbps。
即便是 WiFi7 路由器，由于终端限制，TX 协商依旧只有 2401Mbps。
Macbook Pro 和懒猫微服有线对打（2.5G）
在商店里的 Libre Speed 中测速如下：（APP 内部测速：）
浏览器测速（似乎是有些损失）：
不清楚商店是不是有什么限制，但是如果自己用 playground dokcer 部署就没啥问题：
1 | pg-docker run -p 2333:80 registry.lazycat.cloud/librespeed:23.5.12 |
而在 openspeetest 似乎是有 bug：
使用域名（全有线）
1 | iperf3 -c micro.heiyu.space (base) 12:15:39 |
如果换 IP 可以跑满
1 | ❰xu❙~❱✔≻ iperf3 -c 192.168.31.9 -R (base) 12:15:02 |
懒猫的无线网卡是 AX210，这么看这个吞吐量还是不错的。
1 | iperf3 -c <懒猫无线地址> |
Macbook Pro 和懒猫微服无线对打(WIFI7)，这个数字显然没有那么好看。咨询了路由器的售后，得到了这几个结论：
- 民用的 WIFI 都是半双工，所以一个路由器下两个设备对打速度减半
- 民用的 WIFI 网卡上传可能有阉割
- 即使用 4 收 4 发的路由器无法避免这个问题，因为通道不是独立的
- RX 协商速率偶尔降到 6，可能与 beacon 帧有关（通信的东西不懂，先记下来）
1 | ❰xu❙~❱✘≻ iperf3 -c <无线私有 IP> (base) 12:45:16 |
整体折腾下来，我的结论是：
如果你之前习惯用 NAS 或开发机折腾网络配置，那么上手懒猫微服一定会觉得“省心很多”。它不仅能满足日常访问需求，在高带宽场景下也能撑得住。
一句话总结：懒猫微服不仅仅是“内网穿透神器”，更是一台性能靠谱的迷你服务器。
]]>很多朋友刚接触 NAS、Docker 或容器化环境时，都会觉得 IP 地址这种东西似乎理所当然。但等你真的要远程访问、配置代理或者排查网络时，就会发现，知道机器的私有地址是一件非常关键的事。
举几个典型的场景：
虽然在客户端中可以看到网络地址，但是有阵子我修改 br-lan 网桥之后这里就不再显示了。所以才想了个办法来记录网络地址。下面将结合 Python 代码，介绍几种常见的获取私有地址的方法。
下面我会结合 Python 代码和一些常见的工具，介绍几种获取私有地址的常见做法，并分析它们的优缺点。
首先我们要搞清楚：什么是 私有地址？
私有地址是 RFC1918 标准定义的局域网网段，常见的有：
10.0.0.0/8172.16.0.0/12192.168.0.0/16这些 IP 地址不会直接出现在公网，而是专门留给局域网使用。比如：
192.168.31.2；192.168.1.103；172.18.0.2。所以，获取懒猫微服的“私有地址”，本质上就是找到它在局域网环境下的真实 IP。只有掌握了这个 IP，才能在排查问题的时候得心应手。
在 Python 里，用 socket 模块就能很快拿到主要的私有 IP 地址。代码如下：
1 | import socket |
运行后，输出大概是：
1 | 192.168.1.2 |
这就是懒猫微服当前在局域网里的主要出网地址。
s.connect(('8.8.8.8', 80)) 看似是去连接 Google 的 DNS，其实并不会真正发起网络请求；getsockname() 返回的就是这个网卡对应的本地 IP。127.0.0.1。这种方法非常适合：家用网络 / 有默认出网口 / 多网卡机器。
很多人还会写成：
1 | import socket |
这段代码通过 主机名解析 来获取 IP 地址，看似简单，但问题不少：
127.0.0.1；/etc/hosts 或 DNS 配置，如果没配好，就会失效；所以，这种方法虽然一行就能搞定，但更适合在 主机名规范配置过的服务器，不太推荐在 NAS、容器、虚拟机这些环境里依赖。
如果环境比较复杂，比如同时有 Wi-Fi、以太网、虚拟网卡、容器网桥，只拿一个主要地址就不够了。这时候就需要直接列出所有接口的 IP，再从中筛选。
ifaddr安装：
1 | pip install ifaddr --root-user-action=ignore |
代码：
1 | import ifaddr |
输出是：
1 | eth0: 192.168.5.203 |
psutilpsutil 是更常见的运维库，信息更全面：
1 | pip install psutil --root-user-action=ignore |
代码：
1 | import psutil, socket |
输出会展示每一个网卡的 IPv4 地址：
适合在 虚拟化/容器/复杂网络环境 中使用。
如果列出来的地址很多，还混杂了公网 IP，怎么办？可以用 ipaddress 模块过滤：
1 | import ipaddress |
这样就能快速区分哪些是真正的私有地址，避免混淆。
说了这么多，回到实际应用。获取私有地址到底能帮我们解决什么？
为容器配置反向代理
在 Caddyfile 中写：
1 | reverse_proxy http://192.168.1.2:11434 |
就必须确认 192.168.5.203 真的是懒猫微服的地址。
跨设备访问服务
想用手机访问 NAS 提供的 Web 服务 http://192.168.1.2:8080，也必须提前知道 IP。
排查网络问题
当遇到容器内服务报错（403、502）时，确认是不是反向代理到了错误的 IP，就靠这一步。
| 方法 | 示例代码 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| UDP 连接法 | s.connect(('8.8.8.8', 80)) | 跨平台、常用、结果准确 | 需有路由/网络 | 获取主要私有地址 |
| 主机名解析 | gethostbyname(gethostname()) | 简单，一行搞定 | 常返回 127.0.0.1，依赖配置 | 主机名已配置正确 |
| ifaddr | ifaddr.get_adapters() | 列出所有接口，跨平台 | 需安装库 | 多网卡、容器环境 |
| psutil | psutil.net_if_addrs() | 常见运维库，信息全面 | 需安装库 | 系统监控、诊断 |
| ipaddress | ip_address(ip).is_private | 能区分公网/私网 | 需结合其他方法 | 过滤私有地址 |
获取懒猫微服的私有地址，其实就是获取机器在局域网里的 IP。
socket + 8.8.8.8 方法，几乎百分百靠谱；gethostbyname(gethostname())，但要注意经常只会返回 127.0.0.1；ifaddr 或 psutil 列出所有接口，再结合 ipaddress 做筛选。掌握这些方法，你就能在 部署服务、调试容器、配置代理 时快速定位到懒猫微服的真实 IP，避免因为地址不明导致的各种问题。
以后无论是写 Caddyfile 配置、手机访问 NAS 服务，还是排查 403/502 错误，你都能从容地第一时间确认：**我的懒猫微服，到底在哪个 IP 上运行。
]]>很多人看到这句话的第一反应是：“这玩意儿不是一个微服务器吗？还能当闺蜜机？”
没错，这正是这次改装的灵魂所在。我们要做的，不是再造一台设备，而是赋予它一个新的身份——一台有颜值、有功能、有灵魂的桌面伴侣。
懒猫微服（LazyCat MicroServer），是一台小巧、安静、功耗低却功能极强的家庭服务器。它能跑 Docker、能跑容器、能跑 AI 模型，还能当 NAS、路由器、家庭自动化中枢……
但每当我看着它那方正的金属外壳，总觉得：这样一台有潜力的“小猫”，如果仅仅蜷缩在角落默默运算，实在太可惜了。
于是，一个脑洞渐渐浮现：
如果我能让它“抬起头”，变成一台能与我互动的桌面设备，那它是不是可以从“后台工具”变成一个“生活伙伴”？
这便是“闺蜜机”计划的起点。
在真正开搞之前，我先明确了“闺蜜机”的几个核心需求：
于是，我从硬件角度进行了改造规划。
首先要解决的，就是外观与摆放问题。
我在网上找了一个通用闺蜜机支架，价格大约 100 元出头。直接就可以把带有 VESA 接口的显示器放上去。
接线部分只有三条主线：
硬件准备好之后，就是灵魂的部分：让懒猫“活起来”。
开机后，懒猫智慧屏会显示一个简洁的启动界面。
等待片刻，你就能看到主界面上已经安装好的各种应用：懒猫相册，懒猫网盘，懒猫导航等等。
因为没有配备实体遥控器，我采用了浏览器远程访问的方式来操作图形界面。
只需在电脑上输入懒猫智慧屏的地址，就能看到相同的桌面画面，并进行鼠标和键盘控制。
这一步的意义很大——意味着你可以：
懒猫系统的远程桌面功能做得相当稳定，延迟极低，堪比本地操作体验。
比如在 MoonTV 中搜索“陆小凤传奇”，张智霖太帅了。
播放效果如下图所示，很流畅。在那一刻，几乎会忘记这是一台服务器输出的画面。 现在它更像一台高颜值的桌面智能显示器，可以用来看剧、刷视频、听音乐。
当然，“闺蜜机”的定义不仅仅是娱乐工具。 它更像一个“个人助理终端”，能陪你工作、陪你放松。懒猫微服+智慧屏的组合还能解锁更多玩法：
从某种意义上说，这台改装“闺蜜机”已经超越了硬件定义，它更像一种新的桌面生活方式。
它是你写代码时的终端，是你放松时的屏幕，是你日常信息流的窗口——
更是一个静静陪在你身边、懂你的“小伙伴”。
当一个小小的懒猫微服，既能陪你写代码，又能陪你看剧、听歌、聊天、思考——它就不再是一台设备，而是一种生活方式的具象化。
从技术角度看，它展示了软硬件结合的极致灵活性；
从生活角度看，它代表了一种新的“桌面哲学”：
技术不只是生产力，它也能成为陪伴力。
有时候我们折腾设备，并不是因为它实用，而是因为那份创造的乐趣。
当一个原本冰冷的硬件，因为你的想法与双手，变得有温度、有灵魂——
那一刻，它就成了你的“闺蜜”。
这次改装只是个开始。
也许不久之后，“闺蜜机”会成为每个桌面爱好者的新宠——
一个能理解你的节奏、陪你共度时光的数字伙伴。
懒猫微服，从此有了另一种人生。
]]>这一次，我们换一个更通用、更贴近生产实践的方式：使用应用商店里的 OpenID Connect（OIDC） Provider —— Casdoor。Casdoor 是一个开源的统一身份认证平台，支持完整的 OIDC 协议，可以作为独立的 IdP（Identity Provider）对接到任何应用。通过它，我们不仅能跑通最标准的授权码流程，还能深入理解 OIDC 的关键环节：授权跳转、Token 换取、ID Token 验签以及用户信息获取。
我们经常听到 单点登录（SSO）、OAuth2、JWT 这些词。
OIDC（OpenID Connect）正是基于 OAuth2 的标准化身份认证协议。它的核心作用是：
一个形象的比喻：
OIDC 的标准授权码流程（Authorization Code Flow）：
built-in 组织，可以直接用，也可以新建一个。
在左侧菜单选择 Application → 点击 Add。
填写基本信息：
my-oidc-app）。
在 Authentication 部分：
设置 Redirect URIs：
必须和你应用里写的一致，例如：
1 | http://localhost:5001/auth/callback |
在 OAuth 授权类型 部分：勾选 authorization_code（最标准的流程）。
保存后，在应用详情页可以看到：
同时，Casdoor 服务提供一个 OIDC Discovery 地址：
1 | https://<casdoor-server-domain>/.well-known/openid-configuration |
这个地址返回 JSON，里面包括：
issuerauthorization_endpointtoken_endpointuserinfo_endpointjwks_uriend_session_endpoint这些就是在后端应用里要配置的参数。
在浏览器里直接访问：
1 | https://<casdoor-server-domain>/.well-known/openid-configuration |
如果能看到 JSON，说明 OIDC 服务已开启。
1 | { |
用 Postman 或者 oidc-client 测试一下授权流程，看看能不能拿到 code、access_token、id_token。
✅ 至此，Casdoor 端就配置好了。剩下的就是在应用端（RP）写 OIDC 客户端代码
1 | import os, requests, jwt |
这个是.env 的环境变量：
1 | FLASK_SECRET_KEY=replace-with-a-random-32-bytes-string |
下面是代码解读：
Flask 应用 = OIDC 客户端（RP）；Casdoor = 身份提供方（IdP）。
/login：把浏览器重定向到 IdP 的 授权端点。/callback：IdP 回调携带 code → 后端用 code去 令牌端点 换 access_token + id_token → 用 JWKS 公钥校验 id_token → 用 access_token 拉 userinfo。/profile：展示从 userinfo/ID Token 得到的用户信息。/logout：清空本地会话。1 | import os, requests, jwt |
requests：调 OIDC 的 HTTP 端点。PyJWT + cryptography：验证 id_token 的数字签名。PyJWKClient：根据 JWT 头里的 kid，自动从 jwks_uri 拉对应公钥。urlencode：把授权请求的参数拼到 URL 上（避免手写字符串拼接出错）。1 | load_dotenv() |
.env 读取 Issuer / Client / Secret / Redirect URI，和 Casdoor 后台登记的必须完全一致（协议、域名、端口、路径一字不差）。1 | discovery = requests.get(f"{ISSUER}/.well-known/openid-configuration").json() |
1 |
|
1 |
|
id_token，回调后核对一致（防重放/混淆响应）。Demo 为了短小，先写了固定值。写文章时要强调：生产必须随机、并在回调里校验。
1 |
|
?code=...&state=... 回来。这里先取出 code，并处理错误场景（用户取消授权等）。1 | # 1) 用 code 换 token |
client_id/client_secret 放表单（本例）；id_token（JWT，证明“你是谁”）和 access_token（调用 userinfo 的 Bearer Token）。1 | # 2) 验证 id_token（必须做） |
PyJWKClient 会读 JWT 头部的 kid，去 JWKS_URI 拉这把钥匙的公钥。iss/aud/exp/iat/...。如果你还用了 nonce，建议对 claims["nonce"] 做一致性校验。1 | # 3) 拉取用户信息 |
id_token 里带全资料，所以通常再拉一次 userinfo。access_token。1 | # 4) 缩小会话，只存最小字段（避免 Cookie > 4KB） |
1 |
|
1 |
|
清本地会话即可。若要单点登出，可以再调用 IdP 的 end_session_endpoint（用 Discovery 取到）并带 post_logout_redirect_uri。
通过这次实战，我们完成了一个从 Casdoor 配置 到 应用端代码实现 的 OIDC 流程。
这说明在懒猫微服中，大家不仅可以直接用内置的 OIDC 功能，还可以自由选择商店里的 OIDC Provider（如 Casdoor） 来扩展身份认证能力。
懒猫微服不仅能用自带的 OIDC，更能灵活调用商店里的 Casdoor 等 Provider，满足更灵活的认证与单点登录需求。
]]>虽然现在有了 懒猫微服 的客户端就能直接解决，只需要在手机或者电脑上安装客户端，就可以无缝连回家里，自动切换内外网，无需额外配置。回头看看这一路的折腾，依然让人感慨良多。决定记录下来。
最早接触远程桌面，大多数人用的就是 TeamViewer、ToDesk 这类软件。
它们的优点是：安装简单、即开即用，不需要额外配置公网。对于刚入行的新人来说，能在办公室远程操控家里的电脑，那就是神技。
但是，缺点也很明显：
可以说，这个阶段只是“远程控制的启蒙”。
花生壳 算是让我第一次接触到了“内网穿透”这个的启蒙开始。
他的出现，让我意识到：
那时用花生壳搭建博客、Web 服务，甚至把实验室的算力卡、NAS 暴露到外网，已经让人兴奋不已。
遗憾的是，免费额度有限，带宽不高，延迟非常大，有时候甚至打洞不成功。
虽然限制不少，但花生壳无疑为内网穿透的发展“埋下了种子”。
后来在晚上搜索方案。得知了一个叫做FRP（Fast Reverse Proxy）的项目。
后来我选择在阿里云学生机上自建 FRP，实现公网访问。
这一阶段的特点是：
但问题也随之而来：
一次偶然的网上冲浪，看见 B 站 UP 主推荐蒲公英盒子，于是下单购买了一个。蒲公英盒子 把穿透功能做成了“小黑盒”，即插即用，免去复杂配置。
它的优势是：
但它也有局限：
所以最后我弃用了这个方案。
联通还能给动态的公网 IP，所以可以在路由器上开端口转发了。
公网 IP 的优势不言而喻：
但问题是：
所以，公网 IP 是一个选择，但是并不是最终的方案。
某年某月，外出一段时间，于是用树莓派做了一个监控放在家里推流，然后通过 http 暴露在互联网上，但是没过几天就被封端口了。回来检查内网一切正常。
直到朋友给我推荐了 懒猫微服，这条漫长的折腾曲线才真正画上句号。
它带来了超稳定的内网穿透体验，让我无论身处何地，都能丝滑访问家里的设备。
硬件级双重验证，彻底杜绝黑客攻击；一线工程师贴心支持，让人不再为复杂配置而焦虑。
几乎开箱即用，自动识别并切换内外网，真正做到零额外配置。
下面这张测速图，是我在旅游途中、相距家中千里之外时的真实测得。懒猫微服本身不做任何限速，访问体验就像设备就在身边，再也不用为防火墙、端口映射这些恼人的问题烦恼。
我现在的常用使用场景如下：
网络入口可以选择不同的颗粒度，微服所在局域网（物理网卡），容器内（虚拟网桥） ，登陆微服的客户端或者特定的客户端，或者包括前面所有的规则。
出口也可以选择不同的应用，客户端，甚至是没有登陆微服的客户端，只要网络可达，都可以做流量转发，实属一个居家必备的网关。
它几乎集合了之前所有阶段的优点：
对我来说：
只需一个懒猫微服，就能把 远程运维、开发调试、家庭娱乐 全部串联起来。
从 TeamViewer → 花生壳 → FRP → 蒲公英 → 公网 IP，
这是我的的远程访问修炼史，也是一路的折腾与妥协。
如今，懒猫微服成了真正的终结者。远程访问不再是负担，而是一件轻松、省心的事。
未来可期，组网无忧。
]]>这并不是一台路由器或者 NAS，而是一款 KVM over IP 设备。在传统企业机房里，这类设备往往被用来实现服务器的远程管理：即便服务器关机、系统崩溃，管理员依然可以通过远程方式查看屏幕、控制键鼠，甚至重装系统。过去，这样的功能往往属于 Dell iDRAC、HP iLO、Supermicro IPMI 等服务器管理模块的专属领域。但现在，Gl.iNet 把它做成了一台独立设备，价格和使用门槛也被大大降低，让普通运维人员和 Homelab 爱好者也能体验到“企业级远程管理”的能力。
换句话说，如果你想远程操作一台服务器，哪怕它彻底关机、哪怕系统崩溃，甚至你要给它重装系统，这个小小的设备都能帮你完成。这类设备过去通常是企业机房里的“高端选配”，但现在，Gl.iNet 把它带到了大众可用的价位。
在进入具体体验之前，我们先谈一谈 为什么 KVM over IP 设备重要。
传统的远程管理方式，大体可以分为两类：
这就好比一台电脑出故障，软件方案只能“看得到桌面才管用”，而硬件方案则能“从按电源键那一刻就开始管理”。对于机房里的运维人员，这几乎是救命的功能。
过去个人用户或者中小企业要实现这种能力，往往需要购买昂贵的服务器管理卡。但如今，Gl.iNet 通过 GL-RM1PE 让这种能力变得可负担，也让 Homelab 用户有机会体验到企业级的远程管理。
GL-RM1PE 的设计理念用一句话概括就是：一根网线，搞定一切。
它把三件事情整合到了一根网线上：
这种“单线极简”的设计，在机房和家庭实验室环境中非常有价值。机房里本来布线就复杂，减少一根电源线就意味着更高的整洁度和更低的维护成本。在家里，少一根插座电源适配器，也能让桌面和机柜更干净。
接口布局方面，设备正面依次是：
侧面还有一个 Type-C 供电口，在没有 PoE 交换机的情况下，可以用外接电源。整体来看，它就像是在任何 PC/服务器上外挂了一个“远程管理模块”。
KVM 能解决大部分远程管理问题，但仍有一个关键问题：如果设备彻底关机怎么办？
这就是官方配套的 手指机器人 登场的地方。
顾名思义，它就是一个能模拟“手指按电源键”的小机械装置。
它的设计要点是：
这样，即便远程主机彻底关机，你依然可以通过 KVM 下达指令，让手指机器人去“按电源键”。
我亲测的体验是：在管理后台端点击按钮，机柜里的手指机器人立刻按下动作，把服务器开机了。这种感觉很神奇，就像你拥有了一只可以随时帮你“按开机键”的远程手。对于远程运维人员来说，这意味着再也不用担心“系统挂掉后没人帮忙按电源键”的尴尬。
从外观来看，产品正面有 GL.iNet 的 logo 和 LED 指示灯，铝制外壳配合银灰色表面处理，质感相当不错，放在机柜里也很协调。
在机柜里的实际使用效果如下：
接口从左到右依次是：
侧面还预留了 Type-C 供电口，如果你没有 POE 交换机，可以用外接电源。
拆开手指机器人的外壳，可以看到一个 USB 接收器和一颗 CR2 电池。电池可替换，维护成本不高。
我家里的网络架构是中兴晴天的 AC+AP，完全使用 POE 供电，因此 GL-RM1PE 可以直接插在 AC 上使用（装修时预留了网口）。
接上 POE 之后，设备自动上线，可以通过路由器后台查看 IP。更方便的是，它支持 mDNS，直接访问：
1 | https://glkvm.local/#/ |
就能进入后台管理页面。即使你访问的是 80 端口，那么也会被重定向到 https 的 443 端口，所以这样访问也可以。
1 | glkvm.local |
还可以通过 ping 查找设备 IP：
1 | ping glkvm.local |
Web 管理界面是它的主要入口。
在内网环境下，即便是 KDE 桌面这种对图形要求比较高的环境，WebRTC 的画面流畅度和延迟表现也明显优于 VNC 和 XRDP。以前用 VNC，常常有卡顿和延迟，键盘输入延时明显；而在 GL-RM1PE 上，鼠标和键盘几乎是“秒响应”，就像本地操作一样。
它不仅解决了延迟问题，还提供了专业的视频设置：
无论是普通显示器还是特殊比例的屏幕，都能轻松适配。
声音和输入设备也做得很细致：
此外，它还内置了 剪切板共享、快捷键模拟（如 Ctrl+Alt+Del）、Wake-on-LAN、内置终端 等功能。这些都大幅提升了远程操作的便利性，让体验接近“本地化”。
特别的是，KVM 直接采集 HDMI 输出，即便设备锁屏或休眠，也能远程操作。
远程运维里，最棘手的情况之一是 系统需要重装。如果没有人现场插入 U 盘或者光盘，基本无法操作。而 GL-RM1PE 提供的 虚拟媒体挂载 功能，几乎完美解决了这一问题。
这个非常实用的功能是 虚拟媒体挂载。GL-RM1PE 提供的 虚拟媒体挂载 功能简直是神器。GL-RM1PE 内置 32G eMMC，可以存放主流操作系统的 ISO 镜像。在 Web 界面即可上传 ISO，然后将其作为虚拟光驱挂载。重装系统、文件传输都非常方便。
对于远程运维人员来说，这个功能意味着：你可以在千里之外，帮一台死机的服务器重装系统，而不需要有人在现场插 U 盘。
我在 EndeavourOS x86_64 上成功挂载后，能够看到 PopOS 镜像已经挂载。
设备提供了两种方式：
这个是在 BIOS 中读到的引导项，Gl.iNet Flash Drive 就是这个 GL-RM1PE 的镜像引导，和使用 CD 或者刻录的 U 旁随身碟完全一致。选择 Gl.iNet 的引导之后就进入了我们熟悉的装机环节。
本地用得好，但公网场景怎么办？
Gl.iNet 直接在产品里送了一个 终身免费的内网穿透服务。
电脑端可用 PC 客户端
手机/iPad 可直接访问 https://www.glkvm.cn
这个网址来访问。即使在公网环境下，也能远程访问设备。
因为官方提供终身了内网穿透的功能，所以这是一个买硬件送穿透服务的。
这等于硬件买了之后，官方帮你免去了搭建反向代理、DDNS 的折腾，性价比更高。
使用云服务的话，需要注册账户，然后每次需要登录这个账号。如果你有特殊的安全需要，还可以设置二次验证的 MFA。
设备绑定完成后会显示在列表中，点击远程控制时需重新输入密码，以确保远程管理过程中的安全可靠。
更强的是，它还能接入 Tailscale，加入私有组网，这样能够更加方便的进行异地组网。
如果你之前使用过 Tailscale 的话，那么只需要点点鼠标就能轻松加入之前的组里面。
我把 Macbook，群晖和 GL-RM1PE 放在了一个虚拟局域网里面，这样即使没有公网 IP 也能直接互联。
体验过程中我发现，GL-RM1PE 本身就是一台小型 Linux 机器：
GLKVM 同时还支持终端访问，甚至可以看到是 BusyBox 的环境，这个对于开发者十分友好，甚至还可以 ssh 到内网的 Linux 机器。而且我们也能够看到，有线网卡的协商速率是 1000Mbps。
在 htop 里能看到完整的 4C1G 配置，用来跑 WebRTC 推流完全足够。
机器提供了 32G 的 eMMC,挂载在 /userdata/media，能存放系统 ISO 或作为文件服务器使用。
也就是说可以把这个硬件当作一台小型 Linux 服务器来使用，比如执行python -m http.server可以开启一个文件服务器，当然，BusyBox 环境不支持包管理和 Docker，但作为应急环境、调试环境，已经非常有价值。
如果把 GL-RM1PE 放到整个远程管理市场中，它的定位非常独特。
对于个人和中小企业来说，GL-RM1PE 正好填补了中间空白：比软件方案更可靠，比企业级方案更便宜。
体验下来，我认为 GL-RM1PE + 手指机器人 是一套完整的远程管理解决方案。它把过去属于企业级服务器的功能，带到了个人和中小企业可用的价位。
优势总结：
无论是 IT 运维工程师，还是喜欢折腾的 开发者与 Homelab 爱好者，这套组合都非常值得一试。它不是冰冷的“机房专属”设备，而是把远程管理做到了极客友好、开箱即用。同时也期待 WIFI 版本的 KVM 远程控制器早日上市，这样就更加方便了。
]]>“这台没有公网 IP 的云服务器，还有办法让别人访问吗？”
这其实是很多人都会遇到的情况：
那么，有没有办法“曲线救国”？
答案是：当然有。靠的就是 懒猫微服的端口转发功能。
它能让一台没有公网 IP 的云服务器，重新获得对外访问的能力，甚至还能跨懒猫账号共享。
我把这种玩法类比于 HTTPS 的证书卸载，称之为 “登录卸载”。
朋友的云服务器上跑着一个 Web 服务，但因为没有公网 IP，只能在内网访问。
我的解决方案是：
这样一来，即便服务器本身只有内网地址，也能借助另一台机器的公网出口，对外提供服务。
此时，只需要在这台服务器上安装懒猫微服客户端，然后记住它的机器名称。
出于数据安全的考虑，我给他单独开了一个子账号。
因为当转发目标选择“微服客户端”时，只能获取到登录账号下的设备。这也意味着我无法直接读取他机器的域名，更不能帮他添加转发规则，所以需要让他自己登录来配置。
在懒猫微服的控制台里，他只需要新建一个端口转发规则：
完成后，这台云服务器的服务就顺利“挂”在了公网出口上。
配置好后，我先在内网直接用 telnet 验证：
1 | telnet a.b.c.d <port> |
可以看到，不登录的情况下直接访问懒猫的私有 IP 就能通。
我自己家里有公网 IP，于是只需要在路由器上再做一个转发，就能让这台云服务器的服务真正跑到公网去。
当他看到成功连上之后，才彻底放心：
原来真的能让一台没有公网 IP 的云服务器，也能被公网访问！
为了更方便，我还配合了 DDNS-go 使用。这样即便出口 IP 改变，也能通过域名自动解析到最新 IP，保证随时可访问。
经过这套操作，这台“没有公网 IP 的云服务器”，就像普通云主机一样，可以被外网直接访问了。
关键是：全程不需要购买昂贵的公网 IP，配置好之后也不必频繁登录管理，真正做到一次设置，长期使用。
现在网站的流量数据已经很好看了：
一句话总结：
有了懒猫微服 + DDNS-go，再“抠门”的云服务器，也能摇身一变，获得公网入口。
进入 控制面板 → 通知设置，在通知服务里选择 Webhook。这样群晖就能通过 Webhook 推送消息到 Server 酱。
选择 自定义提供商，规则我这里选择了 监听全部，这样所有通知都会转发。
这里的“提供商”和“主题”随便写，自己能认出来就行。真正关键的是 URL 和请求体。
Server 酱的接口地址是：
1 | https://sctapi.ftqq.com/<key>.send |
保存后群晖会自动在后面拼接一段：
1 | text=%40%40TEXT%40%40 |
这里的 @@TEXT@@ 就是一个占位符，表示群晖实际推送消息时会自动替换成通知内容。
这里是 webhook 的重头戏，所谓 webhook 其实就是 app 里预留了一个 POST API，规定好请求体，然后给用户自由发消息的权利。server 酱接受 title 和 desp 两个字段，无论是 parms 或者 body 都接受。
所以我在群晖 Webhook 的请求体里添加了对应的 JSON：
配置完成后，随便触发一条系统通知，就能看到 Server 酱成功收到了推送：
整个配置思路其实很简单：
这样一来，无论是停电、磁盘告警，还是系统更新提醒，群晖的消息都能第一时间通过 Server 酱推送到手机上。
]]>相信很多人听过 Bitwarden。而 Vaultwarden 是社区开发的 Bitwarden 服务端的轻量级实现，最初叫 bitwarden_rs，后来改名为 Vaultwarden。它用 Rust 编写，资源占用小，非常适合个人用户或者轻量自建场景（树莓派、低配 VPS 等）。它是社区实现的轻量替代版，完全兼容 Bitwarden 的官方客户端，部署成本低，特别适合个人或小团队自建。
在懒猫商店可以直接下载这个应用，安装和使用指南可以参考社区的帖子：玩机攻略:一个开源的密码管理器 Vaultwarden
我在 Bitwarden 的 Wiki 中找到了一份迁移指南：先从 1Password 导出数据，再在 Vaultwarden/Bitwarden 中完成导入。
在 1Password 中导出：文件 -> 导出 -> 项目名字。我这里选择导出 1PUX 格式的文件，存到本地。这样之前保存的密码、SSH Key 等信息都可以完整导出。
然后在 Vaultwarden 网页端导入刚才的 1PUX 文件（需要提前新建一个文件夹）。
操作很简单，导入后数据就都同步过来了。
如果习惯使用客户端，也可以直接在 App Store 下载桌面端。
除了 MacOS，Vaultwarden 同样支持 Windows 和 Linux。
在客户端的最下面可以切换服务器地址，我这里填的是：https://vaultwarden.name.heiyu.space/。
这样在 APP 里就能直接看到刚刚导入的数据，不需要再手动复制粘贴。
除了 APP，还可以使用浏览器插件，Vaultwarden 支持了大多数主流浏览器。
我平时用 Chrome 最多，所以直接在 Chrome 商店下载了插件。
和桌面客户端一样，需要先设置好自己部署的服务器地址。
登录流程和桌面端一致。
我在设置里打开了自动填充功能，这样日常使用方便了不少。
例如登录路由器后台时，Vaultwarden 就能自动填充密码，点击登录即可。
整体体验下来，Vaultwarden 已经完全替代了我之前的 1Password：功能齐全、部署轻量，还能节省一笔订阅费用。对于个人或小团队来说，确实是一个非常值得的平替方案。
]]>
当时整个人都愣住了，Chrome 好像一夜之间“失魂落魄”。
重启浏览器、重启电脑都没用。只好先切到 Safari 搜了下，结合我前几天的操作，很快锁定了问题。
几天前为了玩《植物大战僵尸 2》网页版，我调整过 Chrome 的 ANGLE 渲染引擎。没想到新版 Chrome 对这个配置并不兼容，直接导致渲染器初始化失败，从而整机白屏。
既然问题出在 GPU 渲染，那就先让 Chrome 绕开 GPU，加速器禁用掉再说。
在 macOS 上，可以用命令行启动：
常规方式：
1 | open -a "Google Chrome" --args --disable-gpu |
绝对路径方式：
1 | /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-gpu |
这样 Chrome 会强制禁用 GPU，页面就能正常显示了。
进入浏览器后，把图形渲染器改回默认模式，再重启 Chrome，一切恢复正常。
总体来说，梅苑对一人食很友好，很多菜可以点半份，也只收半份的钱，相对来说算是比较轻奢。但是，想想疫情那阵子馋了四季民福的烤鸭，半只也要 150 元（还吃不饱）。那么梅苑的性价比一定比这个要高。
首先门口摆放的就是米其林和黑珍珠的认证，首先这个仪式感就拉满了。没想到第一次黑珍珠给了南京。
整体装修偏古风，可能也是老店的原因吧。并不像是现在一些网红店很华丽的装修。总体是重剑无锋的路线，用菜品说话。东西是好东西，都说他家不怎么做营销。虽然我也反对那种给鸭子听音乐喂牛奶式的广告。金陵饭店目前靠口口相传也不错了。
第一天点的半份金陵烤鸭，没想到在南京这个菜属于凉菜。在北京经常吃小厨娘的烤鸭，现在想来有些不正宗了。因为它确实是烤制，然后放在砂锅里。属于在朱棣之后有改良了一次做法。而我还照猫画虎学着美食博主老高给饭店建议 – 这个热菜一定要把容器加热，这样吃到最后才不会有腥味。。。虽然饭店照做了，但是从南京回来，感觉它那个在分歧的路上越走越远了。倒是梅苑这种蘸着调味汁的方式更加好吃。别看它分量小，但是很扎实。这一顿还吃得饱。
鸭血粉丝汤，这一碗 39 元。这肯定是真的鸭血了。能少见的感觉到对鲜血的渴望。豆腐泡和鸭肠这种配菜都很新鲜，粉丝也入口即化。相比之下，不管北京的还是夫子庙的小厨娘都差了很多。江苏这边的鸭血粉丝汤都是大碗的，和北京的小碗不同，所以甚至感觉黑珍珠的价格甚至要比北京的很多商场性价比要高一些，食材更新鲜一些，烹饪手法更好一些。
第一顿整体的样貌，然后被本地人吐槽没吃到精髓。丢美食博主的脸了。
白色的公筷上写着金陵饭店。
隔了一天去二刷饭店。都说盐水鸭是精髓，所以特意点了一份，也带了一份在冯记买的盐水鸭进行对比。虽然说在冯记买的已经很好吃了，但还要说一说区别。首先从鸭肉的品质上讲，梅苑要更胜一筹，但冯记也很好，这绝不是四季民福和地毯烤鸭的区别，而是一个肉质紧实而有弹性，一个香腻而软烂。这似乎在印证没有一个鸭子能够飞出南京的玩笑。
盐水鸭用的应该是几十年的卤水，然后就很容易联想到李碧华《吃卤水鹅的女人》里面的桥段。越是老卤则味道越浓厚。
那是一大桶半人高，浸淫过数十万只鹅，乌黑泛亮香浓无比的卤汁。面层铺着一块薄薄的油布似的，保护那四十七年的岁月。它天天不断吸收鹅肉精髓，循环再生，天天比昨日更鲜更浓更香，煮了又煮，卤了又卤，熬了又熬，从未更换改变。这是一大桶“心血”。
不过一个人去吃确实有些咸，只能不断的喝水，吃饭，然后慢慢吃不下其他东西。虽然看着不多，最后还是勉强吃完。
东坡肉是我在任何饭店必点的一道菜。其中最让我惊艳的是北京清水亭的黄州东坡肉。清水亭在我心中的地位比湖北当地很多必吃榜还要好吃。而梅苑的东坡肉又是另外一种滋味，五花三层，香而不腻，尤其这过程中还慢慢用小火去煨肉，肉皮的软烂和肥瘦融为一体。也算弥补了在杭州吃东坡肉的遗憾吧。而在北京小厨娘的东坡肉或者红烧肉性价比堪比和平饭店。所以这就是没有感觉到黑珍珠很贵很贵的原因吧。
看着墙上这一堆荣誉，感觉没白来吧。或者说，来都来了，干脆吃好一点。哦对，米饭是免费吃的。真的很友好了。下次要带着朋友一起去吃松鼠桂鱼。
在效率工具圈子里，飞书多维表格一直被公认是“隐藏神器”。
但尴尬的是，它原本只能在飞书 App 里用。
多少人因为要下载飞书、注册账号，被拦在门外：
所以，飞书多维表格虽然口碑好，却始终没能“全民普及”。
但今天，它终于等来了历史性的一刻：
✨ 飞书多维表格支持“单飞”！
👉 不需要下载飞书
👉 不需要注册账号
👉 打开链接就能直接用
入口直达：点击免费体验飞书多维表格
先别小看这一步。
这意味着：飞书多维表格从一个“附属功能”，变成了任何人都能直接用的独立生产力工具。
更重要的是：它还能和企微、钉钉，甚至企业自研 IM 系统打通，真正做到跨平台无缝协作。
对个人，这是门槛的消失；
对企业，这是数字化转型的加速器。
在它之前，我们用的茶传统表格有以下弊端。
结果就是：要么“太重”，要么“太浅”。
飞书多维表格的出现，正好填补了这个空白：
它既轻量，又专业；既能满足个人使用，又能承载企业核心业务。
一句话：一份数据，N 种角度看。
以前客户和订单分开记，现在只需两张表，一键关联：
这不就是轻量版 CRM吗？
场景示例：
省掉了大量重复劳动。
飞书多维表格自带 AI：
我曾经花一小时写的统计函数，它直接帮我秒写好。
满血功能：不用下载飞书，也能享受百万行、AI、权限、仪表盘。
→ 中小企业可以低成本搭建业务系统。
AI 融入：会用表格就会用 AI。
→ 比如销售日报，让 AI 自动总结“今天卖得最好的是哪款”。
BI 驾驶舱：拖数据进去就能看。
→ 管理层只要打开仪表盘，就能看清业务趋势。
数据库底座：稳载复杂业务。
→ 核心系统不怕数据爆量，性能跟得上。
零代码搭建：业务人员直接动手。
→ 财务自己搭报销系统，运营自己做会员系统，IT 不再背锅。
别以为这是企业专属。对个人和小团队同样好用：
飞书多维表格的“单飞”，本质上是让生产力工具走向大众化。
以前是“飞书用户的福利”，现在是真正的全民工具。
今天的飞书多维表格，已经不是一个“辅助表格工具”。
它是一张能动、能算、能协作的表。
👉 立即免费体验飞书多维表格
👉 官网入口：base.feishu.cn
📌 建议收藏这篇文章：
下次你要做项目排期、客户管理、内容日历、习惯打卡时，直接打开飞书多维表格。
你会发现——表格还能这样玩！
使用容器确实方便了很多事情，但在网络访问上可能会引出一些麻烦。
如果你的调试服务只监听在宿主机的 localhost，那么在容器里访问时，会找的是容器自己的 localhost，所以无法连通。
因为无论是 Coco server 还是 Console 都是服务端发送请求，所以我统一记录下来。
下面介绍几种在不同环境下的解决方案。
在 Orbstack 环境中，可以使用 host.docker.internal 代替宿主机的 localhost。
例如访问宿主机的 Hexo 服务（http://localhost:4000/atom.xml）时，直接这样写：
1 | http://host.docker.internal:4000/atom.xml |
host.docker.internal 会被解析到宿主机 IP，相当于容器内部的 “localhost”。
在 Linux 环境中，host.docker.internal 默认可能不可用，可以用以下方法：
--add-host运行容器时显式添加：
1 | docker run --add-host=host.docker.internal:host-gateway ... |
容器里访问：
1 | curl http://host.docker.internal:4000/atom.xml |
--network host在本地调试时让容器和宿主机共用网络命名空间：
1 | docker run --network host ... |
这样容器里的 localhost:4000 就等于宿主机的 localhost:4000。
⚠️ 缺点：端口可能冲突，不建议在生产环境使用。
在 Linux + docker-compose 场景下，容器访问宿主机的 localhost 同样需要绕过。可以使用以下几种方式（推荐优先使用前两种）：
host.docker.internal1 | version: "3.8" |
容器里访问：
1 | curl http://host.docker.internal:4000/atom.xml |
Linux 默认 docker0 网桥的宿主机 IP 通常是 172.17.0.1，可用以下命令确认：
1 | ip addr show docker0 |
容器里直接访问：
1 | curl http://172.17.0.1:4000/atom.xml |
⚠️ 缺点：如果 Docker 网络结构改动，IP 可能变化。
network_mode: host1 | services: |
容器内的 localhost:4000 直接访问宿主机服务。
⚠️ 缺点同上，失去网络隔离，端口冲突风险高。
0.0.0.0 并用局域网 IP容器里访问：
1 | curl http://192.168.x.x:4000/atom.xml |
其中 192.168.x.x 为宿主机的局域网 IP。
💡 建议：如果 Compose 版本 ≥ 3.4，优先使用 方案 1。写死 host.docker.internal 后，即使宿主机 IP 变化，也能稳定访问。
通过上面的几种方式，无论是在 Orbstack、Linux 单容器 还是 Docker Compose 场景下，都能找到合适的方法让容器访问宿主机的 localhost 服务。
日常调试时，推荐优先使用 host.docker.internal（配合 --add-host 或 Compose 的 extra_hosts），既稳定又无需记 IP；
在容器之间互访，则直接使用 服务名/容器名，让 Docker 自带的 DNS 帮你解析。
掌握这些技巧，既能让 Coco AI 的调试环境跑得顺畅，也能为后续复杂的容器网络架构打好基础。
]]>
我起初以为很简单的事。
1 | ls -l nfs server : not responding total 3580 -rwxrwxrwx@ 1 root wheel 1832497 4 23 2009 e.pdf |
最后在这里找到了答案，由于之前她使用 icloud 同步了整个磁盘，icloud 很快就会满了。再次扩容之后虽然还是保持了卡死的状态。毕竟 apple 这德行。我还经历过把我的 icloud 日程自动同步到其他人的 icloud 里的操作。按照 apple 售后支持这个德行，跟他们说了也是白说。还是直接搜论坛吧：
https://discussions.apple.com/thread/253122585?sortBy=rank
虽然用 ctrl+command + delete 也能删除，但是感觉是元数据层面？
玩硬件，其实也是在找回一些失去的记忆。
这次用到的 SDK 叫 TuyaOpen，它的定位类似 ESP-IDF CLI。
TuyaOpen 同时也支持开发者跨芯片平台、操作系统开发智能设备，代码开源。
跨芯片平台是指支持一些系列芯片，包括 T3, T5 AI，ESP32 等等开发板。
跨操作系统是支持 MacOS，Windows，Linux 全平台开发。对 Mac 党超级友好。
这套工具链对习惯了 ESP-IDF 的人来说几乎是“无缝迁移”。
我这边使用的是 macOS 环境，常用命令如下：
1 | # 1. 克隆源码 |
tos.py config choice：配置芯片型号或项目参数，和 idf.py set-target 类似tos.py build：编译整个工程，输出 bin 文件tos.py flash：将编译好的程序写入开发板tos.py monitor：打开串口调试，实时查看日志这个过程第一次会拉一堆开发工具链。
✅ 小贴士：
tos.py本质上和idf.py是同一个思路，习惯了 IDF 的命令行，就能很快上手。
不过需要注意的是，这三个命令并不能连在一起使用，这个是和 ESP IDF 不同的地方。
在 Linux 下大家习惯用 lsusb，而在 macOS 上则需要借助系统自带命令。
system_profiler1 | system_profiler SPUSBDataType |
能看到所有 USB 总线和设备的详细信息。
ioreg1 | ioreg -p IOUSB |
会以树状结构列出 USB 设备。
我自己装了 usbutils，所以也能直接跑：
1 | ➜ ~ watch -n 1 lsusb |
✅ 小贴士：串口设备在 macOS 下一般表现为
/dev/cu.usbserial-xxxx或/dev/cu.usbmodemxxxx，后面烧录和monitor要用到。
在 M2 MacbookPro 上编译速度还不错，只是偶尔 CPU 会满载：
等终端出现 编译成功 (Build done) 的提示，就说明一切正常，可以进入下一步。
最后就是进入串口调试：
此时如果开发板正常启动，就能在日志里看到打印输出。后续无论是控制外设还是调试联网，串口监控都是必不可少的。
谁说只有 windows 才能玩单片机的。。。
]]>
但是吧，也不是什么严重问题，经常有人搞错，所以正常出站就好了。万一真的错过呢？还可以改签，如果改签过了，找铁路工作人员呗。。。。。。
PS: 吐槽苏州火车站不能刷 12306 二维码进站，然后和复读机吵起来了。我能有什么坏心思呢，单纯的包太多，身份证不好找而已。
]]>
左下角 - 优惠群中心 - 免费 PCB 券。每个月可以领取两张。
然后领取这个 1-4 层专用券，可以抵扣 20 元。不完全测试下仅限标准套餐，打磨什么的需要额外加钱，不能抵扣。
然后回到 PCB，有两种办法
首先确定 DRC 通过，没有问题。
或者导出还是嘉立创主页：https://www.jlc.com/
然后就会跳转到下单的平台，我们可以选择 PCB 的类别和参数，数量就选择 5 个，右边显示价格的地方可以选择优惠券。
选择了优惠券的后，价格直接变成免费。
出货方式选择单片就行，然后板厚 1.0 - 1.6。颜色除了黄色这种冷门工艺，基本都是在免费范围。（可能会有调整）
绿色的板子是最快的，其他颜色会慢 1-2 天。
个性化服务大多数都需要额外付费，所以保持默认就好。
还有一个加 PCB 添加标识的。按照需要使用就好。
SMT 和刚网通通不需要。然后选择快递下单就可以了。
剩下就是收板子。
]]>Coco AI 新增的 本地文件连接器，可以直接接入服务端文件系统，实现秒级搜索、即时访问，让服务器上的文件像本地文档一样触手可及。
本文将介绍如何通过 Docker 快速部署 Coco Server，并配置本地文件连接器，实现服务端文件的智能检索。
Coco Server 是连接器功能的核心组件，部署完成后即可接入本地文件、RSS 等多种数据源。
生产环境建议使用持久化存储，避免数据丢失。
1 | docker run -d \ |
1 | docker run -d \ |
建议生产环境使用持久化部署（第一种方式），测试环境可选择非持久化部署（第二种方式）。
创建用户后，我选择 Ollama 作为模型提供商：
http://localhost:11434deepseek-r1:7b
在「模型提供商」界面可以看到默认启用的 Coco AI，它会直接调用已配置的 Ollama，也支持任何兼容 OpenAI API 协议的 LLM。
Coco AI 默认内置了 官方文档 和 Hacker News 数据源，并在近期新增：
本地连接器的配置非常简单，只需：
如果通过 Docker 部署 Coco Server，需要将本地目录映射到容器内，因为连接器读取的是容器内部路径，而非主机路径。
当然，也可以像我这样直接在 Orbstack 等容器平台上传文件，省去目录映射的步骤。
添加完成后，可以在连接器列表中看到新建的服务端本地文件连接器：
登录 Coco App 后，可以看到刚刚添加的 本地文件 数据源，并直接进行搜索。
这是刚才添加的服务端文件的搜索结果：
此外，Coco AI 还支持客户端本地文件搜索，但本文重点展示的是服务端文件检索功能：
通过本地文件连接器，Coco AI 不仅能帮助你把服务端的文档、日志、配置文件快速接入 AI 检索，还能结合多数据源进行统一搜索，大幅减少人工查找和信息碎片化的时间成本。
未来你还可以将 本地文件检索 与 RSS、API、数据库连接器组合使用，让企业级信息管理更智能、更实时、更高效。
如果你也想让服务器里的海量资料触手可及，不妨部署一个试试——也许你的检索方式，从今天就会不一样。
尤其是对于使用 WordPress 搭建博客或官网的朋友来说，文章虽多，但用户往往需要翻页或依赖站内搜索才能找到所需内容。而如果能把 WordPress 的文章源接入 Coco AI，不仅能实现秒级检索，还可以结合 AI 进行智能问答、聚合分析，让你的内容价值成倍提升。
今天我就来分享一下，如何用 WordPress 自带的 RSS 功能，把文章无缝接入到 Coco AI 中，实现一键搜索全站文章。
在开始之前，你需要：
WordPress 默认的 RSS 地址格式非常简单：
1 | http(s)://你的域名/feed |
为了确保 RSS 链接正常工作，你可以使用 Fluent Reader 这样的本地 RSS 阅读器测试一下。
如果能正常读取文章列表，说明 RSS 输出正常：
为了让 Coco AI 一次获取更多的文章，你可以在 WordPress 后台调整 RSS 输出数量：
接下来进入 Coco AI 管理后台，新建一个 RSS 连接器：
配置完成后，你会在连接器列表中看到刚添加的 WordPress RSS 源：
等待 Coco AI 进行第一次数据抓取，稍后就能在文章列表中看到你的 WordPress 文章：
在 Coco AI 客户端的搜索栏中，直接输入关键词，就能实时搜索 WordPress 全站文章：
点击搜索结果，Coco AI 会直接跳转到对应的 WordPress 文章主页：
通过这种方式接入 RSS，你可以：
只需几个步骤，就能让 WordPress 与 Coco AI 打通，实现全站文章的智能化搜索与访问。
如果你的网站内容很多、更新频繁，这种方法能极大提升读者和你的检索效率，让你的文章真正“活”起来。
使用 Docker 部署是最省心的方式。
1 | docker run -d \ |
1 | docker run -d \ |
测试环境可以用方式 2，生产环境建议使用方式 1，避免数据丢失。
创建完用户后，我直接设置了 Ollama 作为模型提供商：
http://localhost:11434deepseek-r1:7b
在「模型提供商」界面可以看到默认开启的 Coco AI，它会直接调用我配置的 Ollama，也支持其他兼容 OpenAI API 的 LLM。
Coco AI 默认植入了官方文档和 Hacker News 数据源，这次新增了三类连接器：
我们先来安装 Hexo：
1 | pnpm install -g hexo-cli |
Hexo 默认没有开启 RSS，需要通过插件来支持。你可以这样做：
hexo-generator-feed1 | pnpm add hexo-generator-feed |
_config.yml在 Hexo 根目录的 _config.yml 里加上：
1 | feed: |
1 | pnpm hexo clean && pnpm hexo generate |
生成的 RSS 会在 public/atom.xml
选择 RSS 连接器，比如本地调试模式是 localhost:4000：
输入 RSS 地址（这里我用的是我的博客）：
1 | http://host.docker.internal:4000/atom.xml |
刷新时间设为 1 分钟（默认即可）
添加完成后可以看到我同时接入了 S3、本地文件和 RSS：
登录 Coco App 后，可以看到刚才添加的 S3、本地文件和 RSS 数据源：
使用 Coco-AI 搜索时，能快速检索到 RSS 中的内容，效果比博客自带的好很多：
通过 RSS 连接器，Coco-AI 可以实时抓取和索引博客内容，并与本地文件、S3 数据等统一搜索，非常适合做多源聚合知识库。
如果 RSS 输出有限，可以调整博客端的 RSS 配置，让它输出更多历史内容，发挥 Coco AI 检索的最大价值。
]]>举几个例子：
曾经的槽点：某些云厂商直接把开源软件托管来卖，所以才有后来一些厂家改商用 License 的事。
不一定，需要在可用性、经济性、性能之间取舍。
如果个人爱好者真的有需要，还是自己搭建 Homelab 吧。控制好噪音和功耗就行。
]]>使用 Docker 部署是最省心的方式。
1 | docker run -d \ |
1 | docker run -d \ |
测试环境可以用方式 2，生产环境建议使用方式 1，避免数据丢失。
创建完用户后，我直接设置了 Ollama 作为模型提供商：
http://localhost:11434deepseek-r1:7b
在「模型提供商」界面可以看到默认开启的 Coco AI，它会直接调用我配置的 Ollama，也支持其他兼容 OpenAI API 的 LLM。
Coco-AI 默认植入了官方文档和 Hacker News 数据源，这次新增了三类连接器：
选择 RSS 连接器
输入 RSS 地址（这里我用的是我的博客）：
1 | https://airag.click/atom.xml |
刷新时间设为 1 分钟（默认即可）
添加完成后可以看到我同时接入了 S3、本地文件和 RSS：
一开始我发现 Coco-AI 只能显示 最近 20 条，以为是 Coco Server 的限制，后来群友提醒才发现是 RSS 服务端设置的问题。
在博客服务端调整配置后，RSS 就能显示 全部文章 了。虽然很多 RSS 只显示最近内容，但其实可以通过配置让它输出完整数据。
登录 Coco App 后，可以看到刚才添加的 S3、本地文件和 RSS 数据源：
使用 Coco-AI 搜索时，能快速检索到 RSS 中的内容，效果比博客自带的好很多：
点击搜索结果可直接跳转到博客文章。我用的是 Hexo 主题，其他 RSS 源也一样适用。
通过 RSS 连接器，Coco-AI 可以实时抓取和索引博客内容，并与本地文件、S3 数据等统一搜索，非常适合做多源聚合知识库。
如果 RSS 输出有限，可以调整博客端的 RSS 配置，让它输出更多历史内容，发挥 Coco-AI 检索的最大价值。
]]>本篇将详细介绍如何通过 Docker 快速部署 Coco Server，并配置 S3 连接器，完成与亚马逊云科技的无缝集成。
Coco Server 是连接器功能的运行核心，部署好它后才能接入 S3。
生产环境建议使用持久化存储方式，避免数据丢失。
推荐部署方式（生产环境）
持久化存储，避免数据丢失：
1 | docker run -d \ |
测试部署方式（非持久化）
1 | docker run -d \ |
建议生产环境使用第一种部署方式，测试环境可选择第二种。
创建用户后，我选择 Ollama 作为模型提供商：
http://localhost:11434deepseek-r1:7b
在「模型提供商」界面可以看到默认开启的 Coco AI，它会直接调用我配置的 Ollama，也支持其他兼容 OpenAI API 的 LLM。
Coco AI 默认内置官方文档和 Hacker News 数据源，近期新增三类连接器：
选择 S3 对象存储连接器
填写 Endpoint（例：东京区 s3.ap-northeast-1.amazonaws.com）、Bucket 名称、亚马逊云科技凭证（Access Key ID / Secret Access Key），刷新间隔建议保持 1 分钟 默认值。
获取亚马逊云科技访问凭证
这里选择访问密钥 - 创建访问密钥，然后保存 Access Key ID / Secret Access Key 就好。
创建过程中会出现最佳实践提示，不影响后续配置，下载密钥即可使用。
其他的凭证方式虽然有 IAM Role 和 Role anywhere，但是我们这次不会用到。
确保这个用户有访问 S3 的权限，如果是生产的环境的话，确保要采用最小权限原则来防止不必要的麻烦。如果你在存储桶上配置了对应桶策略也可以。
这里的对象前缀可以理解为目录，在 S3 设置之初会把所有文件夹的名称当作前缀加到文件名前面，所以也有 S3 是扁平化管理一说。
完成连接后，S3 中的 Markdown 文件可被 Coco AI 实时索引与检索，点击搜索结果即可跳转到 S3 公网访问链接，例如：
1 | https://<bucket>.s3.<region>.amazonaws.com/<对象名> |
不仅支持标题关键词搜索，还可结合 LLM 实现语义检索，极大提升信息获取效率。
添加完成后可以看到我同时接入了 S3、本地文件和 RSS，我们这里主要开介绍关于 S3 的连接器。
使用 Coco-AI 搜索时，能快速检索到 s3 中的 markdown 文件。
点击搜索结果可直接跳转到对应链接。
也支持把地址复制出来：https://dify233.s3.ap-northeast-1.amazonaws.com/对象名，其实就是S3的https 链接了。
通过 Coco AI S3 连接器，只需几步，即可让 ** Amazon S3** 成为高效智能检索系统的云端引擎。
无论是个人开发者，还是大型企业团队，都能快速构建跨云端、本地、第三方数据源的统一知识平台。
这次入手的大上 Paperlike 系列墨水屏，使用下来有了不少感受。本文就从外观、使用体验到一些细节槽点，和大家聊聊我的真实体验。
最早接触墨水屏显示器，是前年在北京的 SKP。很多年前使用过 kindle，那时候去看墨水屏平板。正巧看到了墨水屏显示器，在店里试用了下很喜欢。相对于很古早的 kindle 而言，国产化的产品更加符合国人的使用习惯化。
和其他产品不同的是，大上的墨水屏有彩色版，所以可以当作外接显示器来用。这么多天使用下来，我比较喜欢的产品的地方竟然是看视频，比如说看《游戏王》，感觉就像是漫画一样。
我的机器是 Paperlike253 的 Mac 版本，到手之后先拍了外观一览，总体很好看，奈何桌子空间内有限，实在摆不下了。M2 的 Macbook pro 只能同时连接两个设备，所以基本是一个外接 4K 屏幕和一个外接墨水屏使用的状态。
相对于最早的 Kindle 来说，大上墨水屏已经有质的飞跃，大上的革命者系列竟然能达到 33HZ 的“高刷”，甚至可以播放一部分的视频。毕竟很早以前的 kindle，连翻页都感觉卡。我这些日子挺喜欢用墨水屏来看游戏王的，虽然是日漫，但是开了视频模式，感觉像是漫画一样。
无论什么电子产品，只要跟 Mac 相关的都需要先做特殊的配置，Mac 版本的墨水屏需要安装客户端来稳定画质，因为苹果的限制。革命者系列自带了一个 HDMI，TYEPC 的线，还有一根 USB-A 转 USB-B 的线。USB 的线是用和驱动软件通讯的。
这里有两个槽点:
- Typec 只用用来传输数据，并不能给 Macbook 供电。
- Macbook 或者 Macmini 都没用 USB-A 的接口了，所以这个线还要转接一下。
这里有一个小技巧就是如果你是双屏幕的情况下，可以把另外一个显示器当作 HUB 用。这又何尝不是一种菊花链？不过还是觉得能够一线通就更好了～
墨水屏显示器的电源适配器是 12V3A，也就是 36W。这个功率在显示屏的圈子里已经很低了。个人感觉后面也可以出一些直流供电的版本，然后就可以使用移动电源或者笔记本 C2C 进行供电。经验而谈，墨水屏在不刷新的时候基本是不耗电的，个人推测这个 36W 主要还是给背光灯使用的。
言归正传，介绍外观。25.3 寸的屏幕使用起来没有比我的 28 寸显示器体感少太多。机身十分简洁，只有左下角有六个按键，分别对应：
C：短按手动刷新，长按记忆模式。
M：切换模式，有自动模式，文本模式，图文模式以及视频模式。
+/- ： 对比度调节大小，右边是色温调节，比如
大大的按键，按压起来软软的，给人一种重剑无锋的感觉。使用起来十分方便。没有花里胡哨的功能菜单，更像是大人的玩具。
显示器背面是标准的 10 * 10 的 VESA 接口，所以这个显示器支架也可以换成市面上通用的支架壁。自带的显示器支架也自带旋转和伸缩的功能，相对于很多显示器自带的支架已经好了很多了。
说回屏幕本身，在熄屏状态，以及没有连接数据线或者没有开启客户端的时候，墨水屏会显示需要信号的图案。这个在致敬有线电视时代的无信号，很有意思。
屏幕有背光灯，所以晚上使用的时候不用担心光源的问题。如果不连接电脑的话，晚上就不会触发这个。
墨水屏同样也支持 HIDPI，在我的 M2 Pro Macbook Pro 上最高支持 1600 * 900 的 HIDPI。基本上就是把原来的 3K 放大了一倍，这一点比很多 3.5K 带鱼屏的 HIDIPI 好很多。之前公司的带鱼屏外接 Mac 总会把下半部分截断，使用起来体验很差，但是在大上的屏幕上就没有这个问题，毫无疑问，这是一个真正合格的 Macbook 外接屏幕。
因为这个事，我还特意调查了分辨率以及 PPI 对 MacOS 外接的影响。大上墨水屏外接几乎没啥违和的地方，屏幕分辨虽然不是 4K，但是在开了原生 HIDPI 使用下完全没有问题。问了客服 PPI 是 145，虽然还达不到 MacOS 的 200+，已经可以达到外接使用的程度了。
计算屏幕 PPI（像素密度）的公式是：
1 | \[ |
对比参考：32 寸 4K 屏幕 ≈ 138 PPI27 寸 4K：≈ 163 PPI
然后再说说这几种模式，图文模式主要针对混排的场景，这样图片能够显示清晰一些。最清晰的还是文本模式，适合纯文本，看电子书，文字网页，这个效果堪比 LCD 显示器。看视频一定要用视频模式（有点废话）。自动模式我很少用。
在几种模式里，我最喜欢的是文本模式，其次是视频模式。文本模式用来看电子书，就是最古早的 Kindle 那种看电子书的感觉，白纸黑字的感觉最好了。这个模式也能用来刷网课，比如一些理论公式什么的，效果竟然比视频模式要好的多。
视频模式主要用来刷剧，比如前面提到的看游戏王。感觉就是在看漫画。另外我在设计 PCB 电路板的时候，使用墨水屏来看渲染模型，也有种物理书的即视感。
美中不足的事看 MV 的效果不算是很好，尤其有些 MV 会出现颜色过暗的问题。还是看日漫吧 hhhh
在不同模式之间切换需要调节合适的亮度和对比度。比如黑色的场景就把对比度调亮一些。文本模式就可以暗一些，这样文字回更加清晰。
刷新率能够达到宣传的 33HZ，尽管和主流 LCD 显示器相比在窗口拖拽方面还是有较大的差距，但是在文字阅读和日常上网方面已经几乎可以当作主力设备来使用了，比如买一个 Macmini，然后外接这样一个显示器无论老人和小孩都能用。（前提是得解决 Paperlike 客户端开机自启动的问题）
在拓展屏的模式下 ufotest 有这个报错，在把墨水屏设置为主显示器之后可以正常显示了。
1 | ufotest SYNC FAILURE: |
背景尽量纯色，这样可以让显示效果更好一些。再来说残影，这是一个不可避免的问题，所以可以在客户端中设置刷新时间，也可以左下角使用 C 按键手动刷新。
墨水屏用着用着就会困，应该是没有蓝光辐射的原因，作为一个科技从业人员，每天面对电子产品和蓝光的辐射，对健康是一个不小的伤害，很多时都在默默承受这一切，虽然慢慢下意识习惯了这一切，但是身体从未忘记。
墨水屏写作，多了一份静心。让我们回归最早的阅读，把电子化和纸质的感觉合二为一可能是未来的趋势。起码现在对于文字工作者来说，在文本模式下写作已经可以很专注了。
总的来说，大上的墨水屏在同类产品里已经算是头部代表，无论是作为护眼阅读设备，还是作为 Mac 的外接显示器，都有着不俗的表现。虽然它现在并不能完全取代传统高刷显示器，但在文字工作、漫画视频和长时间阅读方面，确实提供了一种更加健康和沉浸的体验。
在“屏幕无处不在”的今天，墨水屏或许正在开辟另一条道路。对我来说，它既是工具，也是让人慢下来的媒介。希望未来大上的墨水屏能越做越好，真正成为数字生活与纸质体验之间的桥梁。
]]>请问您觉得有什么我们普通人可以尝试的一些电脑软件方面的操作呢，这些前沿的知识蛮重要，一般人很难知道 🌹
装机，如果追求不多，弄个装系统的 U 盘就行，Windows 安装有手就行。不折腾就用微 PE 工具箱，需要 Linux 共存就用 Ventoy。然后再能换个内存和硬盘就更好了。我习惯于买小配置然后自己升级，当然土豪随意。手不残党还可以上网搜一搜自己换个笔记本屏幕。
安装软件。远离 360 全家桶，xx 大师，xx 精灵，这些不止流氓，还会带一堆的捆绑软件。杀毒软件就用火绒，或者干脆不装大多数情况也没啥事。还有就是再垃圾软件篡改主页之后再改回来，以及更换浏览器的搜索引擎。
分清楚快捷方式和安装软件的区别。很多人把快捷方式一删除就不管了，很多年前遇到过一个妹子倒腾半天最后发过来一个快捷方式给我。请掌握正确的卸载方法（比如 windows 的控制面板）。还要分清楚安装版和绿色版区别。大家都是这么过来的，windows 虽然不好用，但是会强迫你看到一堆的技术字眼，比如 DLL 链接库， .net 框架等等。
分清无线和有线，以及怎么查看动态 IP 地址和配置静态地址。这能够解决大部分电脑不能上网的情况。如果能自己接网线就更好了。
分清楚电脑接口，比如视频线的 VGA，HDMI，DP， Typec。数据线的 USB2.0 和 3.0，不管 3.X 后面多少后缀，他也是当年的 USB3.0。手边常备一个数据线转接头，转 HDMI 或者 USB。
买电脑买新不买旧，不要为了省钱而受罪。配置太低的可能刷网页，写文档都卡。不需要频繁更新系统。
U 盘不要买金士顿。
不要找程序员修电脑。很多人不会，会的也懒得修。
官方文档参考链接：
泰山派烧录镜像说明（官方 Wiki）
嘉立创网盘提供了烧录工具 upgrade_tool，Mac 上直接下载即可。
下载后，记得先给执行权限：
1 | chmod +x upgrade_tool |
主要参考了这个文章，提供了有效的 Mac 烧录方法：
知乎参考文章
泰山派上电开机，用 Type-C 接口接到 Mac。
⚠️ 一定要用高速数据线，很多 Type-C 线只支持充电，没数据功能，用这种线是可能识别不了设备，就算能够识别只有几兆的速度。烧录镜像通常几个 GB 大小，速度差的线也容易出错。
按住开发板上的 REC 按键（不松手）。
此时设备进入 Loader 模式，可以在 Mac 端确认：
1 | ./upgrade_tool ld |
正常输出会显示类似：
1 | Program Log will save in the /Users/xu/upgrade_tool/log/ |
如果能看到 Mode=Loader，就说明设备被正确识别了。
官方镜像是 update.img，把它放到与工具同一目录下，执行：
1 | ./upgrade_tool uf update.img |
正常会输出烧录进度，比如：
1 | Program Log will save in the /Users/xu/upgrade_tool/log/ |
最后出现 Upgrade firmware ok. 就表示烧录完成，可以松开 REC 键了。
整体流程下来，其实在 MacOS 上烧录泰山派并不复杂：
upgrade_tool 工具 + 正确的键位操作；Upgrade firmware ok. 就算成功。
dig 能解析出 IPv6 地址，但容器内网络不可达。https://appstore.lazycat.cloud/#/shop/detail/dev.beiyu.wordpress
dig 查询正常，能返回 IPv6 结果。curl、ping6）失败，提示网络不可达。查询后发现：
在 Orbstack 设置中开启 IPv6 支持即可：
--ipv6 启动参数。开启 IPv6 后，在容器内执行 curl 获取 Wordpress RSS 链接，正常返回内容：
1 | curl https://micro.heiyu.space/feed |
ping6 测试也正常：
1 | [root@5c79a5875d68 easysearch]# ping6 micro.heiyu.space |
总结
在 Mac 上运行的 Docker 容器默认不分配 IPv6 地址，需要在 Orbstack 设置中手动开启 IPv6 支持。开启后无需额外配置，容器即可正常解析并访问 IPv6 目标。
hexo-generator-feed）。因此，要修改 RSS 条数，需要分两步：
在博客根目录（_config.yml 所在目录）执行：
1 | npm install hexo-generator-feed --save |
_config.yml（根目录）配置 RSSRSS 条数由站点配置控制，而不是主题配置。示例：
1 | feed: |
如果不写
limit，默认值是 20（插件源码中var limit = config.limit || 20）。
_config.yml 添加 RSS 链接Icarus 主题只是显示你生成好的 RSS 地址，常见的配置方式有两种：
导航栏：
1 | navbar: |
侧边栏（Profile 小部件）：
1 | widgets: |
1 | hexo clean && hexo g |
然后访问：
1 | http://你的域名/atom.xml |
即可查看 RSS 内容。
hexo-generator-feed 插件控制，只读取 站点 _config.yml 的 feed 配置。_config.yml 中设置按钮或链接。feed: 配置，站点 _config.yml 优先级更高，主题配置不会覆盖它。最早在这个平台上刷到我抄袭我的文章，然后果断投诉下架，值得买和知乎也处理了他的文章。
同时他的公众号也抄袭了这个文章，阅读量有小 1W，转发就有 100 多次，也不清楚到底是赚了多少钱。
更有意思的是，他不仅不道歉而且在公众号上发辟谣。来说不是抄袭之类的。
然后评论区就是一边倒的状态，甚至有说“他就是挂出来挨打的”。
这个是我一开始评论的样子，后来他直接屏蔽我的留言。为了让大家看明白这个事情，所以我贴了我的原文链接。，
过了一天之后发现评论变成了仅作者可见，显然是心虚了，不敢让其他读者看原文。
从工信部的备案中能够查看这个人的信息，还会继续扒其他信息的，也欢迎互联网网友提供。（信息为公开）
抄袭文章，然后连一个公开的道歉都没有么？然后发过来发辟谣说我侮辱他？
简直是素质低劣，屡教不改。我仁至义尽了。
很难不让人认为他其他文章是不是也是抄的，多次沟通让他公开道歉，但是这个态度实在在就是惯犯。
如果有商家想找他合作推广产品，慎重吧。。。
典型的死猪不怕开水烫。
]]>很多的情况是很多原作者流量不高，抄袭的人天南海北的洗，所以流量数字也好看。等被发现或者告了。再来个下架关帐号建新号来逃避法律的追责。如此往复，抄袭者总是能无本获利。我呼吁能够维护原作的知识产权，不要让这种蛀虫危害互联网。
我的文章最早是发在懒猫微服的，后续也发在了亚马逊云科技的公众号上，这个稿件是商业性质了，所以足够够成侵权了。大家记住这个人，虽然他删了帖子，但是再前前后后与他沟通之后，我没有得到他良好的认错态度，所以还是决定把这个文章发出来。
记住这个 ID，这个人有很多平台，有的叫做 panda 不是猫。然后他所有的平台都洗稿了我这个文章，并且流量还不低。而且我的文章是给懒猫微服的商业供稿，就被这个人无耻的剽窃了。所以也很难不怀疑他的其他文章也是不是洗稿来的。
我列出了整个文章的四个抄袭的点，几乎涵盖了所有的项目介绍，而且介绍顺序，功能，隐藏彩蛋，话术丝毫不差。
我的原文：Containly 的核心功能是通过目录央射的 Docker 引擎读取所有容器信息，包括容器的启动、退出、停止及其他:如，当容器处于“Create“状态时它会被标记为“Other”状态，便于管理,
他的洗稿抄袭版本：界面非常清爽，是我喜欢的类型，整个容器就这么一个界面，能看到容器的启动、退出、停止及其他状态。例如，当容器处于“Create”状态时，它会被标记为“Other”状态，便于管理。
这个 other 状态其实埋下的一个彩蛋，绝对不是可以第一次使用的是能够测出来的。
我的原文：默认情况下，每个容器卡片会显容器的网桥信息、端口映射和 URL。默认使用 HTTP 协议，鼠标悬停时，会在右侧显示操作按钮。通过点击这些按钮操作会被保留，再次点击会隐藏，这样子就整个比较美观。
按钮功能包括
他的洗稿抄袭版本：容器卡片会显示容器的网桥信息、端口信息以及 URL 链接地址，默认使用 HTTP 协议，可切换到 HTTPS 协议。
当鼠标悬停时，卡片右侧会显示操作按钮，这里提供了容器的启停重启、日志查看、SSH 功能以及黑名单管理功能，再次点击可以隐藏按钮，显得卡片更为美观。
我的原文：此外，Containly 还提供了一个输入框，用户可以输入需要监控的 NAS 域名，面板会自动根据域名和端口拼接成 URI，并存储在 localStorage 中。更进一步，Containly 还支持暗黑模式，提升了用户体验。
他的洗稿抄袭版本：右上角，Containly 提供了一个地址输入框，在这里填入我们 NAS 的域名或者 IP，面板会自动根据域名和端口拼接成 URI，并存储在 localStorage 中。
我的原文：利用面板的 SSH 功能能够直接从面板进去访问容器的 SHELL，不用执行再 docker exec 的命令。
他的洗稿抄袭版本：利用面板的 SSH 功能能够直接从面板进去访问容器的 SHELL，不用执行再 docker exec 的命令。
（原文一个字没改）
把两篇文章扔到 GPT 里，也判断为洗稿。
根据您提供的两篇文章内容，第二篇文章显然是Containly 项目的原创介绍，详细描述了项目的背景、功能、部署方式以及开发过程。第一篇文章则是对第二篇内容的转载，几乎没有进行实质性的修改或添加新信息。因此，第一篇文章属于抄袭行为。
如果您是第一篇文章的作者，建议您对内容进行充分的改写，或者注明原文出处，以避免版权问题。如果您是第二篇文章的作者，您有权要求删除或修改未经授权转载的内容。
先是公众号上告诉他涉嫌抄袭洗稿，但是没有任何效果。
然后给我回复了这个，完全没有意识到自己错在哪里。
我于是贴证据给他，然后就被无视了。他用我这个文章流量也不少，看 100 多的转发应该也赚了不少的广告费。
抄袭他人稿件，然后用来盈利。除了微信的平台之外，其他平台也不会有太少的广告费。
根据著作权法第 10 条、第 52 条第 5 项及第 53 条第 1 项，对方未经许可复制并在信息网络向公众传播我的文章，已构成剽窃及侵权，应承担停止侵害、赔礼道歉并赔偿损失的法律责任。
第五十四条 侵犯著作权或者与著作权有关的权利的，侵权人应当按照权利人的实际损失或者侵权人的违法所得给予赔偿；权利人的实际损失或者侵权人的违法所得难以计算的，由人民法院根据侵权行为的情节，判决给予五百元以上五百万元以下的赔偿。
为制止侵权行为所支付的合理开支，也可以酌情计入赔偿数额
那再给一个机会吧，然后加微信聊聊，说不定有悔意呢（实时证明我单纯了）
然后对方一开始没理不饶人，简直认为原创。
给了他半个多周的时间来整改，然后就没有然后了，再也没回过我消息。这种无耻的人，还是把他发出来，让大家避雷吧，这种靠抄袭别人还振振有词骗流量的人，才是当代互联网的蛀虫。
本文仅陈述可核实事实，所引用截图均为证据保存；如有异议可联系作者。
这个人微信号在他平台上有，不能够算恶意曝光泄漏隐私。
可以不话心思解决 mac 个 windows 关于 Sambda 的兼容问题。
https://github.com/mar10/wsgidav
WsgiDAV 是一个支持 SSL 的独立 WebDAV 服务器，可以在 Linux、OSX 和 Windows 上作为 Python 命令行脚本运行。它的主要功能包括：
WsgiDAV 启用 SSL 加密，确保文件传输的安全性。WsgiDAV 提供了一个实验性的 Docker 镜像，可以在 Docker 容器中运行 WebDAV 服务。安装 wsgidav 和 cheroot：
1 | pip install wsgidav cheroot |
启动 WsgiDAV 服务器并启用匿名访问：
1 | wsgidav --host=0.0.0.0 --port=80 --root=/tmp --auth=anonymous |
--auth=anonymous 启用匿名认证，允许没有身份验证的访问。
--auth=pam-login 启用基于 PAM 的认证（在 Linux 或 OSX 上使用）。
启用 SSL（推荐使用）：
1 | wsgidav --host=0.0.0.0 --port=8080 --root=/tmp --auth=anonymous --ssl-adapter pyopenssl |
拉取 Docker 镜像：
1 | docker pull mar10/wsgidav |
运行 Docker 容器：
1 | docker run --rm -it -p 8080:8080 -v /tmp:/var/wsgidav-root mar10/wsgidav |
WsgiDAV 可以作为 WSGI 应用程序在其他 WSGI 兼容的 Web 服务器上运行。WsgiDAV 是一个灵活、强大的 WebDAV 解决方案，适合用于文件共享、在线文档编辑等应用场景。如果你需要在 Python 环境中快速部署 WebDAV 服务，它提供了简单的命令行启动选项以及 Docker 支持。如果需要更多自定义功能，还可以通过配置文件和 WSGI 中间件进行扩展。
本文将引导你通过 Docker Compose 启动 OpenList，并将其与 Amazon S3 配置，以便通过 WebDAV 协议进行访问。
首先，我们需要通过 Docker Compose 来启动 OpenList 服务。以下是一个示例 docker-compose.yml 配置文件：
1 | services: |
保存该配置后，使用以下命令启动 OpenList 容器：
1 | docker-compose up -d |
启动成功后，OpenList 的 Web 界面将在端口 5244 上可用。你可以通过浏览器访问 http://localhost:5244 进入管理界面。默认用户名为 admin，初始密码可以通过环境变量设置，或者在容器日志中查看。
我用的是 Orbstack，可以很方便的查看容器日志。如果你使用的是 Docker cli，也可以使用 docker logs 进行查看。
一开始，OpenList 容器没有绑定任何存储，所以页面将显示为空白。此时需要点击右下角的“管理”按钮，进入存储配置界面。
/s3），这相当于 Linux 系统中的挂载目录。
s3.ap-northeast-1.amazonaws.com 作为 endpoint。如果你的存储桶位于其他区域，记得修改为相应区域的 endpoint。
为了方便获取你的 AWS 凭证，可以使用以下命令获取当前机器绑定的凭证：
1 | pip install awsx |
如果你使用 uv 管理 Python 环境，可以运行以下命令打印当前用户名和使用的 Access Key 以及 Secret Key：
1 | uvx awsx |
与许多 SDK 的重定向机制不同，如果你在配置中错误地设置了美东区的 endpoint，OpenList 客户端将不会自动在收到 301 重定向响应后转发请求到正确的区域，而是会报错。
例如，如果你将 endpoint 设置为 s3.us-east-1.amazonaws.com，但存储桶位于 ap-northeast-1 区域，你将遇到以下错误：
1 | BucketRegionError: incorrect region, the bucket is not in 'ap-northeast-1' region at endpoint 's3.us-east-1.amazonaws.com' |
解决方法是确保在配置中使用正确的区域，避免跨区域错误。
为了提高安全性，尤其是在将 OpenList 部署到公网环境时，建议启用多重身份验证（MFA）。启用 MFA 可以增加 AWS 账户的安全性，避免潜在的安全风险。
在 AWS 控制台中启用 MFA 后，记得更新 OpenList 中的凭证配置，确保启用了双重认证。
OpenList 默认情况下将用户权限设置为只读。要赋予 admin 用户 WebDAV 的管理权限，请进入“用户 - 编辑”界面，修改相应的权限设置。
完成配置后，OpenList 将自动同步 S3 存储桶的数据。你可以在 Web 界面上方便地进行文件下载、解压、上传文件等操作。
这个是 S3 上页面，可以看到 s3 的数据都被同步到 Openlist 上了。
同时也能够在 Openlist 上在线观看 S3 上的存的视频教程。
同时所有操作都可以通过 WebDAV 协议进行，访问路径为：
1 | http(s)://<ip>/dav |
例如，在 MacOS 上，可以通过 Finder 进行 WebDAV 访问：
http://localhost:5244/dav。
在 Finder 中使用 WebDAV 进行访问：
你还可以使用 Linux 命令行来操作 WebDAV，减少了学习 S3 命令行的成本。
通过使用 OpenList，我们可以轻松地将 Amazon S3 转换为 WebDAV，简化了文件访问和管理。通过本文的步骤，你可以快速启动 OpenList、配置 S3 存储桶，并通过 WebDAV 协议访问存储在 S3 上的文件。希望这篇文章能帮助你更高效地管理 S3 数据，并为你提供更加便捷的文件访问方式。
]]>看了大狸子的教程, 尝试了一下，顺便补充了其他平台的命令。
很多朋友在装系统、改启动项、开虚拟化（VT-x）、关闭安全启动的时候，都需要进入 BIOS/UEFI。但平时开机要拼命按 DEL/F2/F10/ESC 等快捷键，手速还要够快，稍微慢一点就错过了。
其实在 Windows 和 Linux 系统里，都有“命令行直达 BIOS”的办法，简单又优雅。今天给大家写个全攻略。
在 Windows 10/11 打开 命令提示符（管理员） 或 PowerShell（管理员），输入：
1 | shutdown /r /fw /t 0 |
参数说明：
/r → 重启/fw → 重启后进入 BIOS/UEFI 固件设置/t 0 → 立即执行（默认是 30 秒倒计时）执行后，电脑会立刻重启并直接进入 BIOS。
⚠️ 注意：
/fw，如果是 Legacy BIOS 会报错 “找不到环境选项(203)”。msinfo32，检查 “BIOS 模式” 是否为 UEFI。如果命令报错，可以这样操作：
Linux 用户也能一键进入固件设置：
1 | systemctl reboot --firmware-setup |
这个命令支持大多数基于 systemd 的发行版（Ubuntu、Debian、Fedora、Arch 等）。
如果提示不支持，那就只能用开机热键进入。
Mac 没有传统 BIOS，只有 EFI 设置。
Intel Mac：
**Apple Silicon (M1/M2/M3)**：
| 品牌 | 快捷键 |
|---|---|
| 联想 ThinkPad | F1 |
| 联想 IdeaPad | F2 |
| 华硕 ASUS | F2 或 DEL |
| 惠普 HP | ESC 或 F10 |
| 戴尔 Dell | F2 |
| 宏碁 Acer | F2 或 DEL |
| 微星 MSI | DEL |
| 技嘉 GIGABYTE | DEL |
| 微软 Surface | 音量加 + 电源键 |
shutdown /r /fw /t 0，前提是 UEFI 模式。systemctl reboot --firmware-setup。以后再也不用拼手速狂按 F2/DEL 了，直接用命令行一键进 BIOS，优雅又高效。
]]>最新的 release 打开一开始是这样，
然后给作者留言，修复了 MacOS13 上不能运行的问题。（不到 10 分钟作者就改好了 release）
这个程序需要手指始终触摸板，然后一开始需要校准。
校准之后就可以放置物品了。
除了手有点抖之外，总体还不错。
这个页面也很好看，
路人给出的排查：
到了 apple 线下直接强制重启，按一下+， 再按一下- ，然后长按电源键。然后重启解决了。目测是没有硬件问题，只是 IOS 的崩溃。iphone13 也不能再更新系统了。
我也用 GPT 搜到了这个步骤，只是需要按压 20 秒，我按的时间不够。
你遇到了这个问题，可以长按超过 20 秒来重启。
但是，Credit 拿到手之后，如何把它“充值”到自己的 AWS 账户里？下面我结合实际操作截图，为大家做一个完整的图文教程。
首先，登录 AWS 管理控制台，在搜索栏里输入 Billing。
进入 Billing Dashboard，就能看到当前账户的费用情况，包括账单、支付方式和 Credit 使用情况。
👉 示例截图如下：
在这个总览页面，大家可以随时掌握自己账户的消费情况。
接着，在左侧菜单栏找到 Credits，进入代金券管理页面。
这里会列出所有已经绑定到你账户的 Credit，包括：
如果你手上有 AWS 发放的 Promotion Code（兑换码），就可以在这里点击 兑换积分，输入兑换码完成绑定。
👉 输入兑换码示例：（我这个是刚刚兑换完）
点击 Redeem 后，系统会提示你“成功绑定”，这就说明 Credit 已经充值到账户啦！
绑定成功后，再回到 Credits 页面，就能看到新的 Credit 已经显示出来。
接下来，AWS 在结算账单时会 优先从 Credit 中抵扣，只有当 Credit 用尽或过期，才会从银行卡/信用卡中实际扣款。
这意味着，只要你有 Credit，账户就能“免费”使用 AWS 服务一段时间。
整体流程其实非常简单：
👉 登录 Billing Console → Credits 页面 → Redeem credit → 输入兑换码 → 验证到账。
这样，你就能安心使用 AWS 服务，账单会自动优先从 Credit 扣除，大大节省云上的支出。
对个人和企业来说，合理使用 AWS Credit，能帮助大家 快速试错、降低成本、加速创新。
🔥 小结一句：AWS Credit 不仅是一张优惠券，更是你云上实验和创新的“启动资金”。
]]>https://appstore.lazycat.cloud/#/shop/detail/chestnut.app.vdsm
从懒猫微服商店就可以直接下载了，群友上传了 release。
开源地址在这里：https://github.com/vdsm/virtual-dsm
也不需要再搞群晖引导啥的，直接一件安装很方便，最后设置下用户名和密码就可以了。
版本是目前最新的 DSM7.22，相信群晖应该是很多爱好者的第一个 NAS 系统。这些年我一路从 DSM6 走过来，群晖的系统 UI 是越来越好看了。第一件是必须是安装套件，激活文件管理器。
美中不足的是，没有找到群晖的虚拟机管理器。也罢，反正是虚拟机，VM in VM 性能损耗很大，倒是 Docker in Docker 还能接受。
虽然这个存储空间只有 16G，不过嘛，感觉这个大小其实适合尝鲜或者做已有群晖的 backup。不过机械硬盘倒是没有明显的卡顿。
去应用查看器翻了一下，磁盘大小竟然是在环境变量写死的，那么在 V1.38+的 OS 也能通过修改环境变量来换成更大的空间，毕竟数据盘都是 HDD 不差这点空间。
因为我已经有了一个物理机的群晖，上面也跑着虚拟机和打印机驱动的一些软件，所以这个群晖更多是尝鲜，或者说组成一个集群双活。磁盘太小的话，那么我就添加外部的 SMB，其实就是懒猫网盘。
在群晖的文件管理器中 - 工具 - 装载远程文件夹 - CIFS 共享文件夹。
然后输入 SMB 的信息。需要事先选中一个空文件夹。
这个时候发挥 Linux 的 mount 哲学了 hhhhh
然后把群晖自己 SMB 映射出去，还能做一个 SMB 的存储网关。
懒猫网盘和 share 都是 SMB 挂载的其他设备。也能通过这个虚拟群晖的 SMB 一起访问。
怎么洗白？都有懒猫微服穿透和相册了？不用洗了吧！
]]>speedtest 和中科大测速有时候抽风，中兴自带的还不错
手机也可以使用全球网测，
安卓使用花瓣测速
]]>
📷 页面示意：
在创建页面中填写如下字段：
Application Name：如 Console SSO
Homepage URL：建议填写系统主页，例如 https://memos.name.heiyu.space
Authorization callback URL：授权成功后的回调地址，格式如下：
1 | https://memos.name.heiyu.space/auth/callback |
📷 示例填写界面：
提交后，GitHub 将生成：
📷 凭证界面如下：
创建完成后，返回 OAuth 应用列表，即可看到刚创建的应用。
点击应用名可查看授权信息和应用详情：
📷 应用列表和详情视图：
应用列表页面
然后邮件会收到 Github 绑定 Oauth 的通知。
进入系统设置页面：
📷 Memos 配置页面示例：
配置保存后，注销当前账号，登录页面会显示 GitHub 登录按钮。
📷 登录页面展示效果：
通过以上步骤，我们完成了 GitHub 登录的接入流程：
✅ 创建并配置 GitHub OAuth 应用
✅ 获取并填入凭证
✅ 在 Memos 中启用 OAuth 登录
最后成员列表一览：
下载地址：https://app.lizardbyte.dev/Sunshine/?lng=zh-CN
懒猫微服默认没有图形化，所以直接安装串流服务端也没有意义。于是我用懒猫开启了一个 Windows 虚拟机来做服务器，关于后面怎么安装 windows 虚拟机，后面来讲，或者你也可以找一台物理机 windows 来安装懒猫微服的客户端。
然后把 windows 作为串流的服务端（安装 sunshine）。直接 EXE 安装，然后启动之后在浏览器中设置一下串流的密码就好。
为什么不用 RDP？
RDP 的原生限制，想两个人连接同一个屏幕操作，需要改注册表，很麻烦，所以放弃了这个方案。
客户端下载 Monnlight，然后会自动发现局域网设备。（如果是广域网可以考虑组网，朋友之前有试过也可以串流玩 stream）
客户端加入的时候可以使用 PIN 认证，在服务端输入客户端认证弹出的 PIN，然后再输入设备名称。
然后在客户端点击 Desktop 就可以了，第二个设备也可以重复这个操作，实测不会把第一个串流的 Session 挤掉。
我的目的就是用服务器打开懒猫微服的网页，然后两个客户端同时串流玩双人的游戏。
如果是大型游戏的话，可以直接直接从商店下载部署版本，但是这种小游戏还想娱乐一下的，两个人用串流一起玩还是听方便的。
能够看到我用 Ipad 和 Macbook pro 同时串流懒猫微服里的坦克大战，玩双人游戏还可以基本没啥问题的。（只是稍微有点点卡）
也算是圆了一个梦吧。
]]>事先声明，懒猫微服不提供接单服务，但是可以通过贡献攻略和移植应用赚取激励。
挺有意思的一个事，头几天刚刚找过懒猫微服的技术帮我配置 cloudflare 相关操作，顺便学习了一下基本使用，把自己在 AWS 的 Route53 上购买的域名迁移过去了，然后代理到了博客，AWS EC2 服务器，甚至家里的机器。
偶然间在微信群看到这样一个需求，这不就是前两天懒猫微服的技术人员手把手教我做的。cloudflare 有很多操作，之前周围的人还有使用 cloudflare 反向代理到家里的 NAS，然后 obsidian 实时同步笔记连回家的。
于是我给了他三个方案：
客户选择了方案 3，然后接下来就是配置 cloudflare tunnel，甚至不用再配置 A 记录。
/app1, /app2）或多个子域名绑定首先登录到https://dash.cloudflare.com/首页。点击Zero-Trust。
然后选择 网络 - Tunnels ，然后新建隧道来内网穿透。
选择创建隧道，这个哥们是 Windows 的环境，所以隧道类型使用 Cloudflared。
然后选择新建隧道，然后输入隧道名称。
这个时候选择安装 cloudflared 引擎，需要安装一个 agent，基本是全平台都有，甚至还有 Docker 版本的。
然后把 test 子域代理本地的 localhost:8000。
然后通过域名访问就可以了。
这哥们还有一个额外的要求，要开启启动天 Cloudflared ，然后 GPT 了一下
直接启动已安装的 Cloudflared 服务
运行 Start-Service cloudflared 启动服务
使用 Get-Service cloudflared 查看服务状态
设为开机自启
运行 Set-Service cloudflared -StartupType Automatic 将
Cloudflared 设置为自动启动
]]>结语
买 NAS 学的是网络技术，虽然可能是别人眼中的野路子。但是多一分趣味嘛。切身感受到技术的意义。
小李刚从大学毕业，加入了一家快速发展的初创公司，成为了公司的前端开发工程师。这是他人生中的第一份正式工作，他兴奋又忐忑。虽然他在学校里学过一些编程技术，但真正的项目经验还很薄弱。第一天，老板就把他分配到了一个正在开发的 Web 项目中，需要用 Git 进行版本管理。
“小李，这是你需要参与的项目，我们已经把代码推到 GitHub 上了，记得拉取下来工作。”老板简短的几句话让小李有点懵。
“GitHub？拉取？我听说过 Git，但从来没用过。”小李在心里嘀咕着。他记得在学校的课堂上，老师提到过 Git 作为一种版本控制工具，可以帮助开发团队协作，但具体怎么使用，还是个谜。
“小李，别担心，我们的团队里有很多 Git 使用经验丰富的人，你可以请教他们。”老板似乎察觉到他的一丝不安，轻轻拍了拍他的肩膀。“首先，你得把代码克隆到本地。”
“克隆？那是什么？”小李心中更是一阵迷茫。
他的同事小王看出了他的困惑，走过来笑着解释：“Git 是一种分布式的版本控制系统，‘克隆’是从远程仓库复制一份代码到你本地电脑上的操作。你只需要使用 git clone 命令，把我们的仓库拉下来就行了。”
小李点点头，拿起电脑，打开命令行，准备开始他的 Git 之旅。
小李根据小王的提示，打开了 GitHub，找到了公司项目的仓库链接。接着，他按照小王的指示，输入了以下命令：
1 | git clone https://github.com/company/project-repo.git |
他按下回车键，屏幕上出现了下载的进度条，Git 开始从远程仓库将项目文件拉取到本地。当下载完成后，他看到自己的本地目录下多了一个与仓库同名的文件夹，这时，他才恍若大悟，原来 Git 仓库就像是一个储藏库，而 git clone 命令就是让这个储藏库的内容变成了他自己本地的副本。
“小王，这样我就能开始写代码了吗？”小李兴奋地问。
“是的！不过在你修改代码之前，你需要查看一下当前的状态。” 小王笑了笑，接着说：“输入 git status 命令，它会告诉你当前文件夹里的文件是否已被 Git 跟踪，是否有变更。”
小李按照提示输入了 git status，屏幕上显示出一长串信息，告诉他哪些文件被修改了，哪些文件没有被 Git 跟踪。
“原来 Git 会这么细致地记录每个文件的变化啊！太厉害了。” 小李感慨道。
经过短暂的适应，小李开始修改代码。他添加了一些新的功能，并修复了一个小 bug。这时，他想把自己做的更改提交到 Git。
“小王，接下来该怎么办？”小李再次求助于小王。
“你需要先使用 git add 把修改的文件放到暂存区，然后再用 git commit 提交到本地仓库。” 小王耐心地解释道。
小李按照步骤执行：
1 | git add index.html |
“提交完成了！” 小李兴奋地说道。
小王接着补充道：“记住，提交信息要简洁明了，别人可以通过这些信息快速了解你修改的内容。”
小李点点头，觉得这比学校的作业提交要简单多了。每一次修改都能被记录下来，每一次提交都可以清晰地说明自己做了什么。
小李第一次提交到本地仓库后，心里有了些许成就感。接着，他又向小王询问：“如果我想把本地的修改推送到远程仓库，应该怎么做？”
“你需要用 git push 命令来推送你的提交到远程仓库。” 小王笑着回答，“不过，在推送之前，你需要先从远程仓库拉取最新的代码，避免和其他人的修改发生冲突。”
“哦，明白了。”小李迅速输入了：
1 | git pull |
当他成功将本地修改推送到远程仓库时，屏幕上出现了“push successful”的提示。他心中不禁涌现出一股自豪感：“原来，Git 还真是方便，和团队合作时，每个人都能在同一个项目上协同工作！”
几天后，团队里另外一位开发者小张修改了同一个文件，并且推送到了远程仓库。小李接着更新了代码库，准备继续开发时，突然遇到了一个问题。
“Git 说我无法推送，提示我当前分支落后于远程分支。”小李看着终端输出的错误信息，感到有些困惑。
小王走过来看了一眼，解释道：“这是因为你在推送之前没有拉取最新的远程代码，Git 检测到远程仓库有你没有更新的提交，因此推送失败。”
“那该怎么办？”小李焦急地问。
“我们需要先拉取远程的更新，解决可能的冲突，再进行推送。”小王平静地说道。
于是，小李输入了：
1 | git pull origin main |
Git 检测到有冲突文件后，小李被要求手动解决冲突。经过一番调试，他成功解决了冲突，并将自己的更改再次推送到远程仓库。
“解决冲突是 Git 使用中的一项重要技能，虽然有点麻烦，但熟悉了之后就能游刃有余。” 小王笑着提醒他。
这一天，小李结束了一天的工作。他站在公司楼下，深吸一口气，觉得整个世界变得更加清晰。Git，这个曾经陌生又让他感到害怕的工具，现在已经变成了他开发工作中不可或缺的伙伴。
“小王，谢谢你教我这么多。” 小李感激地说。
“不用谢，我们都是一个团队。” 小王微笑着回答。
随着日子的推移，小李对 Git 的理解越来越深入。每当遇到问题时，他不再感到焦虑，而是学会了从容应对。在这条开发道路上，Git 已经成为了他忠实的伙伴，帮助他高效管理版本，协同开发。
随着项目的不断发展，小李逐渐熟悉了 Git 的基本操作，代码管理变得越来越得心应手。然而，随着开发人员数量的增加，项目中的提交历史开始显得越来越凌乱，尤其是一些多次合并的提交记录，看上去非常混乱。
有一天，小李在查看 Git 提交历史时，发现每次合并分支的提交记录都让历史显得很复杂：“这样下去，历史会越来越乱，别人查找问题的时候会很麻烦。”
小李向小王请教，是否有办法将这些杂乱的提交历史整理得更加简洁。
“你可以使用 git rebase 来整理提交历史，” 小王解释道，“git rebase 可以把你的提交历史进行重新排列，将一些不必要的合并提交压缩成更简洁的历史记录。”
小李兴奋地想试一试。于是，他在 Git 上执行了 git rebase -i 命令，进入了交互式 rebase 模式。这个命令让他可以查看最近的几个提交记录，并选择哪些提交需要保留，哪些提交需要合并。
1 | git rebase -i HEAD~5 |
Git 打开了一个编辑器，列出了最近的 5 次提交记录。小李看到，之前的一些功能开发提交被频繁地合并，而这些合并的记录并没有特别的意义。他决定将这些不重要的提交进行合并。
通过将不必要的提交标记为 squash（合并），小李简洁地将历史整理得更加简洁，并减少了重复的合并提交。整理完成后，他使用 git push 推送了这些更改。
当他看到远程仓库的提交历史变得清晰简洁时，心中充满了成就感。原来，Git 不仅是一个强大的版本控制工具，它也能帮助开发者将代码历史整理得井井有条。
团队开发中，小李和其他同事经常需要在不同的任务之间切换。一天，小李在开发一个新功能时，突然接到紧急任务，要求他修复一个线上 bug。他立即决定中止当前工作，切换到 bug 修复任务。
“小王，怎么才能保证我现在的工作不会丢失呢？”小李问道。
“你可以使用 git stash 命令，把当前未完成的工作保存起来，等你修复完 bug 后再恢复。” 小王笑着答道。
“这可以让我暂时保存当前的工作进展？”小李眼前一亮。
于是，小李按照小王的建议，输入了以下命令：
1 | git stash |
Git 将他当前工作区的更改暂时保存了起来，并恢复了工作目录的干净状态。小李随后切换到了修复 bug 的任务，并快速解决了问题。
几小时后，他回到原先的任务时，使用 git stash apply 恢复了之前未完成的工作。
1 | git stash apply |
小李惊讶地发现，所有的更改和修改都完好无损地恢复了过来。通过 git stash，他不仅没有丢失任何代码，而且能够在不提交的情况下，顺利切换任务。
这让他深刻体会到，Git 是多么强大的工具，在团队协作和多任务处理中，它能够帮助开发者高效管理代码和进度。
项目中的一个新功能上线后，客户突然反馈了一个 bug，导致页面无法正确显示数据。小李接到任务后，立即开始调查这个问题。但问题是，线上代码已经迭代了好几个版本，谁也不清楚到底是哪一次提交引入了问题。
“小王，如何才能定位到具体是哪个提交引入了 bug 呢？”小李问道。
“你可以使用 git bisect 来进行二分查找。”小王回答道，“git bisect 可以帮助你快速找到 bug 引发的提交。它会将历史提交分成两部分，每次告诉你一个范围，你只需要标记 bug 是否存在，Git 会逐步缩小范围，直到找到问题的根源。”
小李恍然大悟。于是，他开始使用 git bisect 查找 bug 的根源：
1 | git bisect start |
git bisect 会从最近的提交开始，将所有的提交历史分成两部分，并让小李检查每一部分是否存在 bug。每次，他都根据测试结果输入“good”或“bad”，Git 会根据他的反馈继续缩小范围。
最终，Git 在经过几轮查找后，成功定位到某个特定的提交，这个提交引入了 bug。小李修复了 bug 后，通过 git bisect reset 重置了 bisect 状态，返回到正常的开发流程。
“原来 Git 不仅可以帮助我们管理版本，还能高效地找出问题的根源。” 小李感叹道。
随着团队中成员越来越多，开发中出现的合并冲突也越来越频繁。虽然小李已经掌握了一些 Git 的基本操作，但每当遇到合并冲突时，他还是感到有些紧张和不知所措。
一天，他在合并一个分支时，遇到了一个棘手的冲突，Git 无法自动合并他和其他同事的更改。
“小王，怎么解决合并冲突呢？”小李有些焦虑。
小王笑了笑，走过来耐心地解释道：“Git 会标记出冲突的地方，你需要打开冲突文件，手动选择保留哪部分代码。解决完冲突后，再执行 git add 和 git commit。”
小李按照指示，打开了冲突文件，看到了被 Git 标记出来的冲突部分。经过仔细的分析，他决定保留自己的修改，并删除了无关的部分。
解决冲突后，小李使用了以下命令：
1 | git add . |
“解决了！这次我终于顺利地解决了冲突。”小李长舒一口气。
“别担心，冲突在团队开发中很常见，解决起来也是一种成长。”小王鼓励他说。
从这次经历后，小李对 Git 的理解更加深刻，他开始不再畏惧合并冲突，反而在解决冲突的过程中积累了更多的经验。
时间过得飞快，随着项目的逐步推进，小李越来越熟悉了 Git 的使用。一次，团队的新需求要求他和小张一起共同开发一个新功能。项目中由于要对数据接口进行修改，涉及到的代码文件较多，这也意味着双方必须频繁地同步代码，避免重复工作。
“小李，你负责前端页面的改动，我负责后端接口的修改。我们需要保持代码同步，你把你的修改推送到 Git 仓库，我拉取下来进行合并。” 小张提醒道。
“好的，小张，我会尽量减少冲突的。” 小李点点头，心里想着如何避免两个开发者在代码中的修改冲突。
小李根据约定，开始在本地开发工作并修改了部分前端代码。当修改完毕后，他通过 git add 和 git commit 提交了自己的修改。接着，他输入了 git push 命令，将本地的更改推送到了远程仓库：
1 | git push origin feature-frontend |
随着“push successful”的提示，修改成功上传到了远程仓库。小李心里松了一口气，开始等着小张拉取他的代码进行合并。
然而，小张这边也在进行着自己的开发工作，修改了后端接口，并且同样进行了提交。当小张准备将修改推送到仓库时，却遇到了困难。“小李，我拉取了你的代码，但是推送时遇到了错误，说我本地分支落后于远程分支。”
“哦，那是因为我在你推送之前就已经提交了我的修改。你需要先拉取我的更改，再进行推送。” 小李知道问题所在，告诉了小张解决方案。
小张理解地点点头，输入了 git pull 来拉取最新的修改：
1 | git pull origin feature-frontend |
Git 自动将小张的修改和小李的修改进行了合并，并解决了没有冲突的部分。小张再一次执行 git push，这次成功了。
“解决了！感谢你，小李。” 小张松了口气，“这就是协作开发的魅力，不同的代码能在 Git 中无缝连接。”
小李微笑着点头，虽然有时遇到一些小麻烦，但通过 Git，这一切变得简单而高效。在远程协作中，git push 和 git pull 成为他日常开发的两大法宝，每次与团队成员一起开发时，他都能高效同步、解决冲突，确保项目的顺利推进。
随着项目的不断进展，小李和团队的开发进度也越来越顺利。为了标记项目中的一些关键版本，项目经理提出了一个新的要求：“我们需要为每个阶段的发布版本创建一个 tag，便于后续的版本管理。”
“tag，我之前只听说过，但是不太明白具体怎么用。” 小李略显困惑。
“没问题！” 项目经理一边解释一边操作，“tag 就是给某个特定的提交添加一个标签。它通常用来标记版本号，例如 v1.0、v1.1 等。你可以通过 git tag 命令为某个提交打标签。”
小李立刻打开了终端，输入了如下命令，为当前版本打上了标签：
1 | git tag v1.0 |
他通过 git tag 命令查看了所有的标签：
1 | git tag |
“tag 是不可变的，它就像是一个时间戳，标记了某个关键时刻的版本。” 项目经理接着说，“如果以后想要回到某个版本，可以通过 git checkout 切换到这个标签。”
小李按照提示，通过 git checkout 轻松地切换到标记为 v1.0 的版本，查看了之前提交的代码，并发现 tag 真的非常方便，帮助他回溯项目的重要节点。
每当开发到一个新阶段或发布一个新版本时，小李都习惯性地为当前版本添加一个 tag，以便将来能够快速回顾项目的重要里程碑。
有一天，小李接到一个紧急任务，需要修复生产环境中的一个 bug。由于 bug 可能影响整个系统的稳定性，他必须马上开始处理，但又不想打乱当前正在开发的其他功能。
“小王，我在本地修改的功能还没有完成，怎么办才能保证现在的修改不会丢失？” 小李有些焦急。
小王走过来，笑着告诉小李：“你可以用 git stash 把当前修改暂时存起来，等你解决完 bug 再恢复。这样就能保证你现在的工作不会丢失。”
小李恍然大悟：“哦，原来可以这么灵活处理！”
于是，他输入了：
1 | git stash |
Git 会暂时保存小李当前的修改，并将工作目录恢复到干净状态。他迅速切换到修复 bug 的任务中，解决了线上问题。当任务完成后，他输入 git stash apply 恢复了之前未完成的功能开发。
1 | git stash apply |
“小王，你看，修改恢复了！不管处理什么任务，Git 总能让我保持高效！”小李激动地说。
小王笑着点点头：“是的，Git 不仅帮助我们管理版本，还能在繁忙的开发过程中高效地切换任务。Git 的 stash 让你随时可以保存当前进度，恢复工作，不会有任何遗漏。”
有一次，小李在开发过程中进行了一个重大的功能更新，然而在提交后，他很快发现这个功能并没有按预期工作，甚至还引发了其他问题。为了修复这个问题，他需要撤回这次提交。
“小王，我不小心提交了一个有问题的功能，这个提交需要撤回，怎么操作？” 小李有些焦急地问道。
小王没有惊讶，而是轻松地告诉小李：“你可以使用 git revert 来撤回指定的提交，它会创建一个新的提交来撤销之前的更改，而不会影响历史。”
小李跟着小王的步骤输入了：
1 | git revert <commit-hash> |
Git 创建了一个新的提交，撤销了原先的修改。当他查看提交历史时，发现撤销操作被正确记录了，而原来的错误提交没有影响到后续的工作。
“原来，撤销错误提交也能这么优雅地操作。” 小李松了口气。
“Git 的 revert 命令让你可以安全地撤回更改，并在代码历史中留下清晰的记录。” 小王总结道。
随着项目越来越庞大，团队成员的增多，开发方式也发生了变化。为了更好地管理开发流程，项目经理决定采用 GitHub 的 Fork 和 Pull Request 工作流，以便团队成员能在自己的分支上开发功能，并通过 Pull Request 将修改提交到主仓库。
“小李，今天我给你分配了一个任务，你需要在 GitHub 上对项目进行一些优化。你可以直接 Fork 这个仓库，然后在自己的仓库中开发。”项目经理说道。
“好的，Fork 是什么意思？”小李有些疑惑。
“Fork 就是将原始仓库的完整副本复制到你的 GitHub 账户下，之后你就可以在自己的副本上进行开发了。开发完成后，提交一个 Pull Request，把你的修改合并到主仓库里。” 项目经理耐心解释道。
“明白了！那我就去 Fork 一下。” 小李立刻在 GitHub 上点击了仓库页面的 Fork 按钮，将仓库复制到了自己的 GitHub 账户中。
接着，小李通过 git clone 克隆了自己的仓库到本地：
1 | git clone https://github.com/your-username/project-repo.git |
然后，他在自己的仓库中开始进行代码的修改。修改完成后，他通过 git push 将自己的更改推送到了自己的 GitHub 仓库，并创建了一个 Pull Request 请求将更改合并到主仓库。
1 | git push origin feature-optimization |
小李完成了 Pull Request 后，项目经理和其他团队成员开始查看并审查他的代码。经过几轮讨论和修改，最终小李的优化功能被成功合并到主仓库。
通过这种工作流，小李意识到，Fork 和 Pull Request 提供了一种高效的协作模式，开发者可以在独立的仓库中进行开发，不会影响主仓库的稳定性，同时也能保持代码的清晰和有序。
随着项目的需求变得越来越复杂，小李和团队开始考虑如何将代码部署过程自动化。为了减少人工操作，提高效率，小李提议使用 GitHub 的 CI/CD 功能——GitHub Actions。
“小王，我们可以用 GitHub Actions 来实现自动化部署吗？” 小李询问道。
“当然可以！GitHub Actions 是 GitHub 提供的 CI/CD 服务，能够在你每次推送代码时自动触发一系列动作，比如编译、测试、部署等。” 小王一边讲解，一边打开了 GitHub 仓库的设置页面。
小李兴奋地学习着如何配置 GitHub Actions。他创建了一个新的 .yml 配置文件，定义了自动化的流程。每次有新的代码推送到主分支时，GitHub Actions 会自动执行一系列操作，首先进行单元测试，然后编译代码，最后自动将更新部署到生产环境。
小李的配置文件如下：
1 | name: CI/CD Pipeline |
这个配置文件定义了当代码推送到 main 分支时，GitHub Actions 会自动进行代码的检查、依赖安装、测试和部署过程。小李将这个文件推送到 GitHub 仓库中后，团队中的每个成员都能在代码推送后享受到自动化部署的便利。
不久之后，当小李提交代码并推送到 GitHub 上时，他看到 GitHub Actions 自动触发了部署流程，并成功将代码部署到生产环境。每次提交后，他不再需要手动执行部署操作，GitHub Actions 自动为他完成了这一切。
“真是太棒了！这下我们可以更专注于开发，不用再浪费时间在部署上了。” 小李高兴地对小王说。
小王点头道：“是的，自动化部署让我们可以更快速、更高效地推送代码，也减少了人为错误。”
随着项目的扩展，团队决定将一些通用的库或模块独立出来，作为子模块来进行管理。这些子模块将在多个项目中复用，减少了重复代码的编写。
“小李，我需要你帮助把我们当前的公共库添加为 Git 子模块，这样其他项目也可以引用这个库。” 项目经理安排了一个新任务。
“好的，git submodule 是怎么操作的？” 小李询问。
“git submodule 是 Git 提供的一个工具，它允许你将一个 Git 仓库嵌套在另一个 Git 仓库中。你可以在主项目中添加其他的 Git 仓库作为子模块，通过子模块来管理依赖。” 项目经理解释道。
小李按照项目经理的要求，输入了以下命令，将公共库添加为子模块：
1 | git submodule add https://github.com/example/public-library.git libs/public-library |
通过这个命令，Git 将公共库克隆到主项目中的 libs/public-library 目录，并将其添加为子模块。小李继续执行了：
1 | git submodule update --init --recursive |
这样，子模块的所有内容都成功同步到本地。当其他团队成员需要使用这个公共库时，他们只需要在主仓库中执行相同的 git submodule 命令来同步子模块。
“小李，感谢你的帮助！以后其他项目也能通过这个子模块共享公共库了，极大减少了重复开发的时间。” 项目经理赞扬道。
小李点点头，意识到 Git 的 submodule 功能极大地提升了团队的开发效率，让依赖库的管理变得更简单、更灵活。
小李在团队开发的过程中，逐渐接触到了更多的 Git 高级操作。随着项目逐渐向前推进，他发现有时需要从一个分支中挑选特定的提交，而不是直接合并整个分支。比如，有时他只想把某个特定的功能或者修复应用到当前工作中，而不希望将整个分支的其他修改都合并过来。
“小王，有没有什么方法能让我只选取某个提交而不是合并整个分支？”小李问道。
“当然有，”小王笑着说道，“Git 有一个非常有用的命令，叫做 git cherry-pick，它可以让你从另一个分支上挑选特定的提交，并将该提交应用到当前分支。”
小李顿时豁然开朗：“那如果我想把某个功能从 feature 分支中拿到当前的 main 分支上，该怎么操作？”
“你只需要找到那个提交的哈希值，然后用 git cherry-pick 命令把它应用到你的当前分支。”小王答道。
于是，小李开始操作：
首先，他通过 git log 查找 feature 分支中的那个提交的哈希值。
1 | git log feature |
然后，他切换到 main 分支，准备将提交引入当前分支：
1 | git checkout main |
接着，使用 git cherry-pick 来选择并应用那个提交：
1 | git cherry-pick <commit-hash> |
当命令执行后，Git 自动将那个提交的更改应用到了 main 分支上，而不需要合并整个 feature 分支。小李检查了代码，确认应用成功后，顺利地将新功能整合到当前分支。
“小王，真是太棒了！这个命令太实用了，以后再也不用为合并多余的代码而烦恼了！”小李高兴地说道。
小王点头笑道：“对，git cherry-pick 就是为了解决这个问题，它让你可以选择性地引入更改，避免不必要的合并。”
小李开始在日常开发中频繁使用 git cherry-pick，每当他需要从其他分支挑选特定提交时，这个命令都成为了他的得力助手。
在一次代码审查的过程中，小李和团队成员遇到了一些小小的矛盾。由于对某个功能实现的理解不同，大家对如何修改代码意见不合。虽然问题本身并不大，但由于缺乏清晰的沟通，导致开发的进展有些停滞。
“小李，你能给我们解释一下你这次修改的思路吗？”项目经理耐心地询问。
小李站在桌前，深吸一口气，决定用更清晰的方式来表达自己的想法。他打开了 Git 提交记录，逐一展示了自己的修改和思路。
“我在这里用 git commit --amend 修改了之前的提交，因为在初始提交时，我没有充分考虑到性能问题。通过这次修改，我优化了这一部分。”小李一边说，一边展示了代码改动的细节。
项目经理点点头：“明白了，这样修改的确能够提升性能。但是，我们最好在团队中进行一些小范围的讨论，再决定如何优化。”
小李决定更加注重团队的沟通，他理解到 Git 提交的详细记录和清晰的提交信息可以极大地帮助团队成员理解每个开发者的修改意图。在随后的开发过程中，他在每次提交时，都更加注重编写简洁且易懂的提交信息。
“小李，你这次提交信息写得很好，大家都能清楚知道你的修改意图。”项目经理称赞道。
这次经验让小李意识到，Git 不仅是一个版本控制工具，它还成为了团队成员之间沟通的桥梁。通过清晰的提交记录和及时的 Pull Request，每个开发者都能了解其他人的工作，从而更好地进行协作。
随着项目开发的深入，版本发布的节奏也逐渐加快。小李开始频繁接触到版本管理的任务。每当团队开发出一个新功能并完成测试时，他们就会创建一个版本发布，并用 Git 的 tag 来标记发布的版本。
“小李，接下来我们需要为即将发布的版本打上标签。” 项目经理走过来，指着屏幕说道，“你可以使用 git tag 来为我们当前的版本创建一个标签，并标记一个明确的版本号。”
“我明白了，标签就像是一个历史的快照，可以帮助我们标记每一个发布版本。” 小李回答道。
于是，小李在完成最后的代码修改后，为当前的提交打上了一个标签：
1 | git tag v1.0 |
然后，他通过 git push 推送了标签到远程仓库：
1 | git push origin v1.0 |
项目经理看到远程仓库成功更新了标签后，表示满意：“很好，tag 可以让我们轻松标记每次发布的版本，方便后续的维护和版本回溯。”
小李意识到，Git 的 tag 功能不仅能够帮助团队在版本发布时更加清晰地管理项目，还能在遇到回滚或版本回退时快速恢复到特定的版本。随着团队开发的推进，tag 成为了团队工作中不可缺少的工具之一。
随着小李逐渐掌握了 Git 的基础和高级操作，团队中的工作流程也开始更加成熟。在一次团队会议上，项目经理提议引入一种新的 Git 工作流，以便更高效地管理开发和部署过程。
“小李，团队正在采用 Git 的 feature branch 工作流，我们建议每个开发者在开发新功能时，都创建一个新的分支，开发完成后再合并回主分支。”项目经理说道。
“这样可以避免多人同时修改同一代码文件时产生冲突吗？”小李问道。
“没错，”项目经理解释道，“通过使用 feature branch，每个开发者都可以在独立的分支上进行开发，确保主分支保持稳定。只有在开发完成后，才能通过 git merge 或者 git pull request 合并回主分支。”
小李听后对这种工作流产生了浓厚兴趣。他立刻实践了这个流程。在开发新功能时，他从 main 分支创建了一个新的分支，并在分支上进行修改。当功能开发完成后，他执行了：
1 | git checkout main |
通过这种方式，小李能够确保每个功能都能在独立的环境中开发，不会影响其他团队成员的工作。而且，git merge 能够帮助他将所有更改平滑地合并到主分支，确保代码的稳定性。
随着时间的推移，小李不断地在实践中熟练掌握 Git 的各种技巧和工作流，他不仅能够高效地管理代码和版本，还能帮助团队提高开发效率。Git 成为了他工作中不可或缺的伙伴，见证了他从初学者到专业开发者的成长。
每当遇到问题或新的挑战时，小李总能依赖 Git 解决问题。他逐渐明白，Git 不仅仅是一个工具，它更像是一位教练，帮助开发者从错误中学习，从实践中进步。
未来的路还很长，而 Git 将继续陪伴小李，助力他在开发的世界中越走越远。在这个信息化飞速发展的时代，Git 让团队协作变得更加高效，代码管理变得更加清晰，开发者的每一步成长，都将在 Git 的世界中留下深深的印记。
git reset 和 git reflog随着开发项目的不断发展，小李逐渐遇到了一些复杂的情况。有时候，他在提交后发现代码存在问题，或者做了不必要的操作，想要撤回。对于这种情况，git reset 命令成为了他解决问题的利器。
一天，小李正在开发一个新功能，突然意识到自己在提交时选择了错误的文件进行修改，造成了不必要的代码变动。他想要撤回这次提交，怎么做呢？
“小王，我不小心提交了错误的代码，能不能撤回？” 小李焦急地问道。
小王走过来，微笑着解释道：“你可以使用 git reset 来撤回最近的提交。git reset 允许你恢复到某个特定的提交状态，你可以选择是保留本地修改，还是完全丢弃。”
“那如何使用呢？”小李问道。
“你可以通过 git reset --soft HEAD~1 撤销最近一次提交，但保留你的工作区更改；或者使用 git reset --hard HEAD~1 完全撤销提交，并且丢弃所有更改。” 小王继续说道。
小李决定使用 git reset --soft 来撤回错误的提交并保留工作目录中的修改：
1 | git reset --soft HEAD~1 |
执行完命令后，Git 将最近一次提交撤销，并把修改恢复到暂存区。这时，小李可以继续修改代码并重新提交。
“小王，真是太方便了！git reset 让我能够灵活控制我的代码，避免了不必要的错误提交。”
“是的，git reset 是一个非常强大的命令，但要小心使用，尤其是 --hard 参数，使用不当可能会丢失数据。” 小王提醒道。
不仅如此，小李还学会了使用 git reflog 查看历史操作的记录。当他不小心做错操作时，git reflog 成为了解决问题的救命稻草。
“git reflog 是一个很有用的工具，它记录了你所有的 HEAD 操作历史，即便你执行了 git reset 或者其他改变了历史的操作，它也能帮你找回丢失的记录。” 小王向小李展示了 git reflog 的使用。
1 | git reflog |
小李通过 git reflog 快速找到了丢失的提交，并通过 git reset 恢复了之前的状态。这让他更加有信心在复杂的开发任务中使用 Git 来管理版本和操作历史。
随着项目的逐渐深入，团队的代码审查变得尤为重要。小李不再是唯一负责提交和修改代码的人，团队中的每个成员都在贡献自己的力量。而 Git 在代码审查中的作用，也变得愈发突出。
“小李，今天我们来做代码审查，你的这段代码有一些地方需要调整。” 项目经理提醒道。
“好的，项目经理，能不能给我一些反馈？”小李走到项目经理的办公桌旁。
项目经理通过 Git 提交记录查看了小李的代码，指出了其中的一些问题。通过 git diff 命令，他能清楚地看到小李在提交时修改了哪些部分。
“小李，你在提交时改变了这个函数的实现逻辑。我们能不能保留原有逻辑并优化一下性能？”项目经理问道。
小李立刻打开终端，执行 git diff 查看具体的代码差异，确认了项目经理的建议：
1 | git diff HEAD~1 |
“确实是这样。谢谢你指出这个问题，我会按照建议进行修改。”小李认真地说道。
通过 git diff，小李能够迅速查看每次提交所带来的代码差异，确保每次修改都能符合团队的要求。而且，Git 也让代码审查变得更加高效，团队成员可以轻松查看每个提交的改动内容，避免了沟通上的误解。
项目经理总结道：“Git 在团队协作中的优势非常明显，代码审查时，我们能直接通过提交记录看到每个开发者的修改，而且能随时回溯历史，查看每个修改的细节。”
小李深刻认识到，Git 提供的强大工具不仅能帮助他高效管理代码，还能在团队合作中提升代码审查的效率，确保每个成员的代码质量。
随着项目的规模不断扩大，团队决定引入持续集成（CI）工具，以便更好地自动化测试和部署流程。小李负责配置 Git 和 CI 工具的集成，让团队的代码自动化构建、测试和部署。
“小李，我们要使用 Jenkins 来进行自动化构建和测试，能帮我把 Git 和 Jenkins 集成起来吗？”项目经理问道。
“没问题，项目经理，我来配置。” 小李点头答应。
首先，他在 GitHub 仓库中配置了 Webhook，当代码推送到 GitHub 仓库时，Webhook 会自动触发 Jenkins 构建任务。接着，小李在 Jenkins 中配置了一个构建任务，并在构建脚本中加入了自动拉取 Git 仓库代码的命令：
1 | git clone https://github.com/your-username/project-repo.git |
此外，Jenkins 还配置了自动化测试步骤，每当代码推送到 Git 仓库时，Jenkins 会自动拉取代码，执行单元测试，确保没有新的 bug 被引入。
通过这种方式，小李实现了 Git 与 Jenkins 的无缝集成，让每次代码推送后都能自动触发构建和测试流程，极大提高了开发效率。
“小李，你的配置太棒了！现在我们每次推送代码后，Jenkins 会自动进行构建和测试，这样就能第一时间发现问题，避免了手动操作的麻烦。”项目经理感慨道。
小李也深刻感受到，Git 不仅是团队协作的工具，还能与 CI 工具结合，提升整个开发流程的自动化和高效性。
随着小李在项目中不断积累经验，他开始接触到更加复杂的 Git 使用场景。例如，团队中的多个子项目之间需要进行协调开发，这就需要管理多个仓库。为了有效管理这些子项目，小李学习了如何使用 Git 管理多个仓库的代码。
“小李，我们有多个子项目需要同步更新，能不能管理多个 Git 仓库？”项目经理问道。
小李思索了一下，答道：“我们可以使用 Git 的 submodule 功能来管理这些子项目，或者通过 git remote 将多个远程仓库关联到一个本地仓库。”
他通过 git remote 添加了其他项目的远程仓库，使得多个仓库能够通过一个 Git 仓库进行管理。这种方法让小李能够方便地同步多个子项目的代码，并确保所有仓库的代码始终保持一致。
“小李，这种管理方式非常有效，能让我们轻松地同步多个仓库的代码。”项目经理满意地说道。
随着团队逐渐发展，项目的规模也在不断扩大，甚至开始涉及多个跨团队的合作。小李渐渐意识到，在这样的大规模项目中，Git 不再是一个单纯的版本控制工具，而是整个开发流程的核心之一。为了解决不同团队成员之间的协作问题，团队决定采用 Git 作为核心工具来协调各项工作。
“小李，我们的项目越来越复杂，多个团队的协作需求也越来越高，如何更好地协调和管理多个模块之间的关系呢？” 项目经理问道。
“我建议我们将每个模块或子系统作为独立的 Git 仓库，采用 Git 的 Submodule 或者 Subtree 功能来管理不同模块之间的依赖。” 小李回答道，“这样可以让每个团队独立工作，同时通过 Git 的功能保持各个模块之间的同步。”
“Submodule 和 Subtree？能不能再详细说一下？” 项目经理有些疑惑。
“好的，” 小李微笑着解释，“git submodule 用于将一个 Git 仓库嵌套到另一个仓库中，适合在一个大的项目中引用一些公共的库或者子项目。它能够让我们独立管理每个模块，并通过主仓库来同步这些模块。git subtree 则是一个更强大的工具，允许我们将一个项目的子目录作为另一个仓库的历史部分来管理，方便合并和共享代码。”
项目经理点点头，表示理解：“那我们可以先尝试使用 git submodule，看看能不能有效管理各个子模块。”
于是，小李开始在主项目中引入了 Git 子模块，将各个子模块独立管理，每个团队都可以独立开发自己的部分，通过 Git Submodule 来同步。每当有更新时，团队成员只需使用 git submodule update 命令来同步各自的子模块。
“小李，这样的做法确实很有效。每个团队都可以专注于自己负责的模块，且能通过 Git 保证模块间的同步。” 项目经理满意地说道。
随着项目的不断发展，团队的协作也变得更加高效。Git Submodule 成为了管理大规模项目中多个模块之间关系的关键工具，使得每个团队能够更加高效地独立开发，避免了冲突和重复工作。
随着团队在多个项目中的逐渐积累，团队的开发模式也逐渐从传统的开发方式向 DevOps 转型。持续集成（CI）、持续交付（CD）和自动化测试成为了团队开发的核心需求，而 Git 作为版本控制工具在 DevOps 中的作用变得尤为重要。
“小李，接下来我们要将开发流程进行 DevOps 化，我们需要一个自动化的 CI/CD 流程来提高开发效率。” 项目经理指示道，“你能帮忙把 Git 与我们的 CI 工具结合起来吗？”
“没问题，我来配置。” 小李迅速答应道。
小李首先配置了 Git 与 Jenkins 的集成。每当团队成员向 Git 仓库推送代码时，Jenkins 会自动检测到提交，触发自动化构建流程，执行单元测试，确保每次提交的代码都能够通过测试。接着，他配置了持续交付流程，每当通过测试后，Jenkins 会将代码自动部署到开发环境进行进一步的验证。
为了进一步优化流程，小李还在 GitHub 上配置了 Webhooks，将每次 Git 提交推送事件通知给 Jenkins，确保流程的自动化和即时性。
“通过这种方式，我们的代码每次提交后都会自动构建和测试，减少了手动操作的时间和错误。” 小李解释道，“这种 DevOps 思维方式不仅提升了开发效率，也保证了代码的质量。”
项目经理看着自动化部署流程的顺利运行，表示满意：“非常好，Git 与 DevOps 结合，自动化构建和测试提高了我们的交付效率，减少了人工操作的错误。”
随着小李在公司中积累的经验越来越丰富，他开始参加一些开源项目的开发。开源项目通常有很多开发者参与，其中涉及到不同的工作流和版本管理方式。在参与开源项目时，Git 的使用成为了开发中的一个重要部分，尤其是如何高效地与其他开发者协作。
“小李，最近我在 GitHub 上看到一个非常有意思的开源项目，我们也可以参与其中贡献代码。” 小王激动地说。
“开源项目？那我们要如何参与其中呢？”小李问道。
“我们可以通过 Fork 该项目，并在我们的个人 GitHub 仓库中进行开发。当我们完成自己的功能后，通过 Pull Request 向原项目提交我们的更改。” 小王解释道。
小李立刻开始了解开源项目的工作流程。首先，他在 GitHub 上 Fork 了项目，然后将其克隆到本地。接着，他在本地进行了修改，并在完成之后推送到个人仓库。
然后，他创建了一个 Pull Request，请求将自己的更改合并到原项目中。通过这种方式，原项目的维护者可以查看他的修改并决定是否接受他的更改。
“小李，Fork 和 Pull Request 真是开源项目的核心工作流。它能让我们独立开发，并通过 PR 与原项目进行贡献。”小王感慨道。
通过参与开源项目，小李不仅进一步提升了自己的开发技能，还学会了如何在全球范围内与其他开发者协作。Git 的强大功能使得开源项目的开发变得有序而高效，团队成员之间能够通过清晰的提交记录和 PR 进行有效沟通，确保了代码质量和开发进度。
随着团队的进一步发展，团队决定采用敏捷开发（Agile）方法来提高开发效率和灵活性。敏捷开发要求团队快速响应需求变化，并在较短的时间内交付高质量的代码。而 Git 成为了实现这一目标的关键工具之一。
“小李，我们决定引入敏捷开发，采用迭代的方式进行功能开发。每个 Sprint 结束后，我们需要提交一个可交付的版本。” 项目经理说道，“你认为我们如何利用 Git 来支持敏捷开发？”
“我认为，Git 能够非常好地支持敏捷开发。” 小李答道，“通过创建 feature 分支，我们能够快速开发出独立的功能。在每个 Sprint 结束时，我们可以通过 git merge 或者 git pull request 将功能合并到主分支，从而保证代码的稳定性。”
“那我们如何处理版本发布呢？” 项目经理问道。
“Git 的 tag 功能非常适合版本管理。在每次功能开发完成后，我们可以通过 git tag 打上版本标签，标记每个发布的里程碑。” 小李解释道。
通过使用 Git 支持敏捷开发，团队能够更快速地进行功能开发和迭代交付，同时保持代码的清晰和可维护性。每次迭代结束后，Git 的分支管理和版本标签都确保了每个功能都能够按时交付，且不会影响其他功能的开发。
项目经理表示赞赏：“Git 的分支管理和 tag 功能完美支持了我们敏捷开发的需求，让我们能够更加高效地进行迭代和发布。”
随着时间的推移，小李不仅在公司中积累了丰富的 Git 使用经验，也在开源项目和敏捷开发中不断提升自己。Git 成为了他日常开发工作中不可或缺的工具，帮助他在团队中与其他成员高效协作，推动项目顺利进行。
Git 不再只是一个简单的版本控制工具，它已经深入到整个开发流程中，成为小李的长久伙伴。无论是日常的功能开发，还是复杂的多团队协作，Git 都能够帮助开发者高效管理代码，提升开发效率。
未来的道路依然充满挑战，但小李相信，只要有 Git 作为工具，他将能够不断突破自己，迎接更大的成功。在这个快速发展的技术时代，Git 将继续陪伴小李，在他编程的旅程中不断迈向新的高度。
随着公司项目的规模日益壮大，团队成员也越来越多。小李和其他团队成员发现，Git 在大规模团队中的协作变得更加复杂。在一个多团队、跨部门的项目中，如何有效地管理和合并不同的代码变得尤为重要。
“小李，团队的规模扩大后，我们发现管理多个开发分支变得越来越困难，很多人都在不同的分支上并行开发，合并冲突也变得更频繁了。你觉得我们怎么做才能更高效地管理代码？” 项目经理问道。
小李开始思考，发现随着团队规模的扩大，代码管理面临的挑战确实在增加。他想到了一些改进方法：“我们可以采用 Git Flow 工作流来更好地管理分支。Git Flow 是一个标准化的分支管理模式，它通过规定各个分支的功能来减少冲突，确保每个分支的职责明确。”
“Git Flow？听起来很有用。你能详细解释一下吗？” 项目经理有些好奇。
小李耐心地讲解道：“Git Flow 是由 Vincent Driessen 提出的分支模型，它定义了几个主要的分支角色：
master 分支。feature 分支上开发，开发完成后合并回 develop 分支。develop 分支上的功能基本完成时，我们会创建一个 release 分支来进行最终测试和 bug 修复。master 和 develop。这种工作流的优势在于，每个团队成员可以在自己的特性分支上独立开发，减少冲突。而且，release 和 hotfix 分支帮助我们在发布和修复过程中保持主分支的稳定。”
项目经理听后点点头：“这个工作流确实很有意义，它能够帮助我们更有条理地管理代码，避免过多的冲突和合并问题。”
小李随后帮助团队将 Git Flow 工作流应用到团队项目中，确保每个开发人员按照规范创建分支、提交代码，并使用 git merge 或 git pull request 合并分支。通过这种方法，团队成员之间的协作变得更加高效，而 Git Flow 也为团队提供了清晰的分支管理结构。
随着团队的技术栈不断扩展，项目开始涉及多个平台的开发需求：前端使用 React，后端使用 Node.js 和 Express，移动端使用 React Native，甚至还有一些用于数据处理的 Python 脚本。每个平台的代码和环境不同，但如何确保这些平台的代码都能同步更新、管理起来却不产生冲突，成为了小李的一个新挑战。
“小李，考虑到我们开发的多个平台，如何更好地管理这些不同代码的依赖呢？” 项目经理询问道。
小李回忆起自己在过去的项目中遇到过类似的需求，顿时有了主意：“我们可以利用 Git 子模块（git submodule）来管理跨平台的代码库。通过将每个平台的代码作为独立的 Git 仓库，使用主仓库来统一管理这些代码，就能有效地将不同的代码库集中在一个地方，方便我们管理。”
“你是说，不同的代码库可以独立管理，然后通过主仓库来同步吗？” 项目经理问。
“是的，git submodule 允许我们将其他 Git 仓库嵌套在主仓库中，作为子模块来管理。每个子模块有自己的版本号，主仓库负责对子模块进行版本控制和更新。当我们需要更新子模块的代码时，只需在主仓库中同步子模块即可。” 小李解释道。
他接着为项目配置了 Git 子模块，每个平台的代码库都作为一个子模块被添加进主仓库中，使用 git submodule 命令来同步更新各平台的代码：
1 | git submodule add https://github.com/example/frontend-repo.git frontend |
每当更新子模块的代码时，团队成员只需要在主仓库中执行：
1 | git submodule update --recursive --remote |
通过这种方式，团队能够有效管理不同平台的代码，并确保每个平台的版本都能保持同步，减少了版本冲突的发生。
“通过子模块管理多个平台的代码，团队成员可以独立开发，不同平台之间不会相互干扰。” 项目经理表示赞赏。
随着项目的不断发展，代码质量和团队合作变得尤为重要。小李意识到，除了版本控制和代码同步，如何高效地进行代码审查（Code Review）也是团队合作中的一个关键环节。
“小李，最近我们在团队中遇到了一些代码质量问题。为了提高代码质量，我们决定加强代码审查流程。” 项目经理说。
“我明白，代码审查能帮助团队发现问题并保持一致的编码风格。我觉得 Git 可以在这方面发挥很大作用。” 小李答道。
小李向项目经理提议，通过 Git 提交记录和 GitHub 的 Pull Request 功能，团队成员可以高效地进行代码审查。每次提交新的功能或修改时，开发者都通过 git push 将代码推送到远程仓库，并创建一个 Pull Request，请求团队成员进行审查。
在代码审查过程中，团队成员可以在 GitHub 上查看具体的改动（git diff），留下评论，提出修改意见。每次修改完毕，开发者会更新 Pull Request，直到所有问题得到解决。最终，项目经理或负责人会合并代码并批准最终的提交。
“小李，这个流程非常有帮助，Git 的 Pull Request 功能能让我们更高效地进行代码审查，确保每个功能都经过了充分的讨论和审核。” 项目经理说道。
通过 Git 提供的强大功能，团队能够在代码审查中更好地协作，不仅提升了代码质量，还加强了团队之间的沟通。
随着团队项目越来越复杂，小李开始接触到一个新的需求——自动化。项目中有很多重复性、繁琐的操作，比如同步子模块、打标签、发布新版本等。小李发现，手动执行这些操作既耗时又容易出错，因此他决定通过编写脚本来自动化这些任务。
“小李，我们希望能简化每次发布的过程，能不能帮忙写个自动化脚本，避免每次都要手动执行 Git 命令？” 项目经理提出了一个需求。
小李非常兴奋，因为他一直对自动化非常感兴趣。他思考了一下，决定用 Bash 脚本来实现这一功能。脚本的目标是每次新版本发布时，自动更新子模块、切换到主分支、打标签，并将代码推送到远程仓库。
他编写了如下脚本：
1 |
|
这个脚本首先更新了所有子模块，确保每个模块都是最新的。然后，它会切换到 main 分支，拉取远程仓库的最新代码，接着生成一个基于当前时间戳的版本号，并使用 git tag 打上标签。最后，脚本会将 main 分支和新标签都推送到远程仓库。
“小李，这个自动化脚本简直太棒了！以后发布新版本时，直接执行这个脚本就行了，避免了手动操作的错误。” 项目经理大加赞赏。
小李也对这个自动化过程非常满意。通过自动化脚本，他不仅减少了繁琐的操作，还降低了人为错误的风险。这次经历让小李更加深刻地认识到，Git 不仅是版本控制工具，它也能够与自动化流程紧密结合，提升整个开发流程的效率。
随着团队规模和项目复杂度的增加，沟通变得尤为重要。团队成员之间不仅要讨论功能需求，还需要清楚地了解其他成员的工作进展。小李发现，Git 提供的提交记录、分支管理、合并过程和 Pull Request，实际上都为团队沟通提供了强有力的支持。
一天，小李在查看项目的 Git 提交记录时，注意到某些提交信息比较模糊，无法准确反映开发的进度和内容。他认为，这是团队在使用 Git 时未能充分利用其沟通能力。
“小王，你觉得 Git 提交信息的重要性有多大？”小李向同事请教。
“其实提交信息是团队沟通的一个重要桥梁，它可以帮助我们了解每个功能的开发进度和思路。如果提交信息不清晰，团队成员很难理解开发者的意图。” 小王认真回答道。
“那我们能不能有一个规范，确保每个人在提交时都写清楚相关信息？”小李提议。
小王点点头：“是的，我们可以制定一些提交信息规范，比如每次提交时都写清楚这次提交的目的、所修复的 bug、改进的功能等。这样可以帮助团队成员快速理解代码的变动，提升沟通效率。”
于是，小李和团队一起讨论并制定了一份 Git 提交信息规范，要求每次提交时都必须包括以下内容：
从那以后，团队的 Git 提交记录变得更加清晰和规范，每个人在查看提交记录时都能迅速理解变更内容。Git 不再只是一个简单的工具，它成为了团队沟通的桥梁，帮助开发者更好地协作。
在小李所在的公司，随着项目的扩展，团队成员开始分布在不同的地方，甚至有了远程工作模式。如何保持远程团队的协作效率，成了一个关键问题。小李深知，Git 的强大远程协作能力将在这里发挥巨大的作用。
“小李，考虑到我们团队已经是远程工作，我们需要有一个标准化的流程来管理远程仓库和分支，确保每个人都能高效协作。”项目经理提出了新的挑战。
“我们可以利用 GitHub、GitLab 或 Bitbucket 等平台的功能来实现这一点，配合 git fetch、git pull、git push，保证每个人的工作始终与远程仓库同步。” 小李回答道，“我们可以设置清晰的分支管理规则，例如每个功能使用独立的 feature 分支，合并时使用 Pull Request，并且严格要求审查代码。”
“那这样的话，团队成员都可以在自己的分支上独立工作，最后通过 Pull Request 来进行合并和代码审查，对吗？” 项目经理进一步确认。
“是的，完全正确。每个人都可以在自己的分支上工作，提交并推送到远程仓库后，其他成员可以随时拉取更新。通过 Pull Request 和代码审查，我们可以确保代码质量，避免直接推送到 main 分支。” 小李解释道。
为了更好地管理远程协作，小李还建议团队使用 GitHub 的团队管理功能，将每个项目的成员分成不同的权限组，确保项目代码的安全性。
通过这些措施，团队的远程协作变得越来越顺畅，开发进度也大大加快。Git 成为他们跨时区、跨地域协作的桥梁，保证了远程工作模式下的高效沟通与协作。
在一次团队会议上，项目经理提到：“我们团队已经积累了大量的知识和技术文档，如何能够更好地管理这些知识，让每个新加入的成员都能快速了解项目和技术栈？”
小李听后立即想到了 Git 的优势：“我们可以将这些文档和知识管理工作与 Git 结合起来，创建一个专门的 Git 仓库，来管理项目的技术文档、架构设计以及解决方案等。”
项目经理表示认可：“这样一来，新成员可以通过 Git 仓库查看我们的文档，也能通过 Git 提交的历史记录了解每个问题的解决过程。”
小李和团队决定创建一个专门的 Git 仓库，专门用来存储项目文档、设计文档、代码规范和技术文章等。在这个仓库中，所有文档都将与代码一样进行版本控制，每个文档的更新和修改都会记录在 Git 提交历史中，方便后续查看和追溯。
通过这种方式，团队的知识管理变得更加高效，每个成员都可以随时查看、更新和修改文档，而 Git 则确保了文档的版本控制和更新记录。
随着项目变得越来越复杂，小李发现开发环境的多样化带来了新的挑战。在一个典型的跨平台开发环境中，团队同时在开发前端、后端、移动应用、甚至机器学习模型等多个部分，而每个部分都有不同的技术栈和依赖。
“小李，我们的项目现在涉及多个平台，前端是 React，后端是 Node.js，移动端是 React Native，机器学习模型是用 Python 实现的。如何在这些平台之间保持一致，并且高效协作呢？” 项目经理问。
“这个问题确实不小，”小李思考了一下，“不过我想到了一种方式。我们可以利用 Git 和 Docker 来帮助管理这些平台的环境，确保每个开发者的环境一致。同时，我们可以通过 CI 工具进行自动化测试和构建，确保每个平台的代码都能顺利运行。”
他继续讲解：“首先，我们可以为每个平台创建独立的 Git 子模块，分别管理每个平台的代码库。然后，我们可以通过 Docker 为每个平台创建独立的开发环境，确保每个开发者都能在本地轻松搭建相同的开发环境。”
项目经理表示理解并表示认可：“这个思路不错，Git 的子模块能帮助我们管理各个项目，而 Docker 则能保证每个开发者的环境一致。接下来，你可以为我们实现这一方案吗？”
小李开始实施方案。他为每个平台创建了独立的 Git 子模块，将不同平台的代码库分开管理，确保每个平台的代码能独立开发且相互不干扰。接着，他为每个平台编写了 Dockerfile 文件，确保每个开发者都能通过 Docker 快速搭建一致的开发环境。
例如，前端的开发环境通过 Docker 配置了 Node.js 和相关的构建工具，而后端则使用了 Express 和数据库连接，机器学习的环境则配置了 Python 和 TensorFlow。通过 Docker 容器，开发者只需要拉取相应的容器镜像，就可以快速搭建起完全一致的开发环境。
“小李，这个方案非常棒！通过 Docker，我们能够在不同平台之间确保开发环境的一致性，Git 子模块则让我们能更好地管理不同平台的代码。” 项目经理感慨道。
小李也对这一方案非常满意。通过 Git 和 Docker 的结合，团队能够有效地管理和协作多个平台的开发，避免了环境不一致的问题。同时，自动化测试和持续集成的引入也让开发进度更加高效。
随着项目的功能越来越丰富，数据库的管理也变得尤为重要。数据库结构、存储过程和数据迁移等方面的变动需要进行详细的记录和管理。小李发现，传统的数据库管理方式往往不够透明，难以追溯数据库的变动历史。于是，他提出了一个新方案：使用 Git 来管理数据库的版本控制。
“小李，我看到你最近在研究数据库版本控制的方案。你能给我们讲讲怎么将 Git 应用到数据库管理中吗？” 项目经理问。
“我想到了一个方法，就是通过将数据库的结构和迁移脚本也放入 Git 仓库中，和应用代码一起管理。” 小李回答道。
他接着解释：“我们可以把每次数据库的变动（例如表结构变更、索引创建、存储过程更新等）写成迁移脚本，并将这些脚本放入 Git 仓库中进行版本控制。每当需要修改数据库结构时，开发者只需编写迁移脚本，并将其提交到 Git 仓库。然后，通过自动化工具或者手动方式运行这些迁移脚本，数据库就能与应用代码同步更新。”
项目经理觉得这个方案非常有价值，毕竟数据库的变更往往难以管理，Git 的引入能够帮助团队更好地追踪和管理这些变动。
“小李，你可以为我们建立一个数据库迁移管理流程吗？” 项目经理问道。
小李开始构建这个方案。他创建了一个新的 Git 仓库，用于存储所有数据库的迁移脚本。每次数据库结构有变化时，开发者会编写相应的迁移脚本，提交到 Git 仓库中。迁移脚本的命名规则也被统一，以便于后续的管理和回滚。
当需要更新数据库时，开发者会使用一个数据库迁移工具（例如 Flyway 或 Liquibase）来自动应用这些脚本，确保数据库与应用代码保持一致。如果数据库出现问题，可以通过 Git 历史记录查看之前的变更，并回滚到某个历史版本。
“小李，你的这个方案太好了！数据库变更再也不需要手动记录和更新了，所有的变动都可以通过 Git 来追溯。” 项目经理激动地说道。
通过将数据库版本控制与 Git 集成，团队不仅提高了管理效率，还增加了开发过程中的透明度和可追溯性。
随着项目逐渐走向成熟，小李逐渐意识到，Git 不仅仅是一个技术工具，它也在潜移默化地影响着团队的文化。在团队的协作中，Git 强调了透明度、代码的可追溯性和团队成员之间的高效沟通。
“小李，最近我注意到，团队成员在协作时越来越注重代码的清晰度和规范性，大家的合作也越来越顺畅。” 项目经理感慨道，“你觉得这与 Git 的使用有关系吗？”
小李点点头：“有很大关系。Git 强调了每个人对代码的责任和透明度。每次提交都可以清晰地查看修改内容，团队成员通过 git diff 和 git log 能够清楚地看到彼此的工作。这不仅提升了代码质量，也促进了团队成员之间的有效沟通。”
项目经理继续说：“我还发现，团队成员越来越注重提交信息的规范，大家在写提交信息时，会写得很清晰，标明修复的 bug、优化的功能以及其他细节。这种良好的习惯促进了团队的协作和项目的高效推进。”
小李微笑着回答：“是的，Git 的提交信息规范性确实对团队合作有很大影响。当每个开发者都知道自己提交的每一行代码都需要经过审查并且能被追溯时，大家会更自觉地保证代码的质量和清晰度。Git 让我们在开发过程中养成了良好的编码习惯，也提升了团队协作的效率。”
项目经理点头赞同：“Git 作为我们的核心工具，不仅帮助我们管理版本、协作开发，还帮助我们树立了良好的团队文化。我们现在的开发过程更加高效，团队也更加和谐。”
随着公司项目和团队规模的扩大，小李逐渐意识到，除了版本控制和协作，Git 在保障代码安全性方面也能发挥重要作用。在项目中，团队开始引入 DevSecOps（开发、运维和安全一体化）的概念，确保代码在整个开发周期中都能遵循最佳的安全实践。
“小李，我们最近决定加强项目的安全性，将安全控制纳入到开发流程中，你觉得 Git 在这个过程中能扮演什么角色？” 项目经理问道。
小李思索了一下，回答道：“Git 在 DevSecOps 中的作用主要体现在两个方面。一方面，它能够帮助我们确保代码的安全性，通过代码审查和历史提交记录，让我们清晰地了解代码变动，确保没有恶意或不安全的代码被引入；另一方面，Git 还能够与安全工具集成，通过 CI/CD 管道自动化地检测漏洞，保证每次代码提交都经过安全审查。”
“能举个例子吗？” 项目经理感兴趣地问道。
小李接着解释道：“举个例子，我们可以在 Git 提交时，集成一些静态代码分析工具，例如 SonarQube 或 Checkmarx，这些工具会扫描每次提交的代码，检测潜在的漏洞或安全隐患。如果发现问题，Git 会阻止代码的合并，直到问题被修复。通过这种方式，我们能够确保每个提交都符合安全标准。”
项目经理点头称赞：“这个思路很好，Git 不仅能管理版本，还能与安全工具紧密结合，自动化检查代码中的安全问题。这将大大提高我们的安全性，避免漏洞进入生产环境。”
小李开始为团队配置了与 Git 集成的安全工具。他设置了 SonarQube，确保每次代码提交时，都会自动进行静态代码分析，并通过 Git 的 hook 阻止潜在的漏洞进入主分支。通过这种方式，团队确保每次提交的代码都能符合安全标准，而不需要人工介入。
随着项目架构的复杂性增加，团队决定将项目的开发模式转向微服务架构。微服务架构将应用拆分成多个独立的服务，每个服务都负责一个特定的功能模块，能够独立部署、独立开发，并且通过 API 进行互联。
“小李，随着我们逐渐采用微服务架构，如何高效地管理每个微服务的代码和依赖呢？” 项目经理问道。
“我们可以使用 Git 来管理每个微服务的代码库，确保每个微服务都能独立开发和部署。” 小李回答道，“每个微服务都可以作为一个独立的 Git 仓库来管理，这样能够保证服务之间的独立性，并且可以通过 Git 的 Submodule 或者 Subtree 来管理微服务之间的依赖。”
“小李，那微服务间如何进行版本控制和依赖管理呢？” 项目经理继续问。
“我们可以在每个微服务的 Git 仓库中使用标签（tag）来标记每个版本，确保我们可以回溯历史版本。” 小李进一步解释道，“此外，通过在 Git 仓库中配置 CI/CD 流程，每个微服务都能独立构建、测试和部署，确保每个服务的更新不会影响其他服务的运行。”
项目经理表示赞同：“这样的话，每个微服务就能独立管理，同时保持与其他服务的同步，减少了系统的耦合性。”
小李帮助团队将 Git 应用于微服务架构的管理中，为每个微服务创建了独立的 Git 仓库，并通过 Git 子模块来管理服务之间的依赖。通过这种方式，每个微服务的代码都能独立更新和发布，而 Git 确保了服务之间的同步和版本控制。
随着团队逐渐壮大，协作工具的使用也变得越来越重要。小李发现，除了 Git，本地的代码管理，团队还需要借助 Slack、Jira、Trello 等工具进行任务管理、沟通和协作。为了提高工作效率，如何将 Git 与这些工具集成，成为了小李的新挑战。
“小李，我们希望在每次代码提交时，能够自动通知团队成员并更新任务进度，你觉得 Git 能和这些工具集成吗？” 项目经理问道。
“完全可以，” 小李答道，“我们可以利用 Git 提供的 webhook 功能，将 Git 与 Slack、Jira 等工具集成。当我们提交代码时，可以自动通过 webhook 发送消息到 Slack，通知团队成员代码的更新；同时，我们也可以自动更新 Jira 上的任务状态，让团队成员更清晰地知道当前任务的进度。”
项目经理听后非常赞同：“这能大大提高我们的沟通效率，让每个团队成员都能第一时间知道任务进展。”
小李立即开始为团队配置 Git 与 Slack 和 Jira 的集成。他设置了 GitHub 的 webhook，在每次提交时，自动发送消息到团队的 Slack 频道，告知大家新的功能开发进度或 bug 修复的状态。同时，他也将 Jira 与 GitHub 集成，每次提交代码时，相关的任务会自动更新状态，确保任务进展清晰可见。
“小李，太棒了！通过这种集成，我们的沟通效率大大提高，团队成员能够第一时间看到任务的进展和代码更新。” 项目经理感慨道。
随着技术的不断进步，小李看到 Git 的发展趋势将不仅仅停留在传统的版本控制和协作管理上。人工智能（AI）和自动化工具的结合，将使 Git 变得更加智能化，能够自动分析代码质量，提供代码优化建议，甚至自动修复常见的代码问题。
“小李，你认为 Git 在未来的发展会是怎样的？” 项目经理问道。
“我认为，未来 Git 会与 AI 更紧密地结合，自动化和智能化的特性将进一步增强。” 小李回答道，“例如，Git 将能够通过 AI 自动分析代码的质量、风格和结构，自动生成优化建议，并通过机器学习模型来预测代码的潜在问题。未来的 Git 可能不仅仅是一个代码管理工具，它也可以作为开发中的智能助手，帮助开发者更高效地编写和管理代码。”
项目经理笑了笑：“这个思路非常前瞻，的确，AI 与 Git 的结合将为开发者带来更多的便利。也许在不久的将来，Git 就不再是一个仅仅执行命令的工具，而是一个智能的合作伙伴，主动为开发者提供帮助。”
小李对未来的 Git 充满期待。他相信，随着 AI 和自动化技术的发展，Git 将继续进化，成为开发者不可或缺的智能伙伴，不仅帮助管理版本和代码，更会成为整个开发过程中的决策支持系统。
随着技术的不断发展和项目需求的不断增加，小李渐渐意识到，Git 的功能已远远超出了传统的版本控制工具的范畴。越来越多的团队开始探索如何利用 Git 在更高层次的工作流和管理中发挥作用。小李对 Git 的深度掌握也逐渐使他开始考虑，未来是否有可能会出现新的版本控制系统，或者 Git 会如何进化以适应未来的需求。
“小李，你觉得 Git 在未来会如何发展？是否会有其他版本控制工具取代 Git 的地位？” 项目经理在一次会议中向小李提出了这个问题。
小李思索了一下，回答道：“我认为 Git 目前仍然是最强大的版本控制系统，它已经深深扎根于开发者的工作流中。不过，随着大数据、分布式计算和人工智能的快速发展，Git 可能会在未来进行一些技术性进化，特别是在性能优化、协作和自动化方面。可能我们会看到更多与 Git 集成的工具，或是智能化的 Git 提示系统，甚至 Git 会在管理大规模分布式系统中变得更加高效。”
他继续说道：“目前的 Git 是为开发者和小型团队设计的，但随着大型开源项目和企业级开发的需求增加，Git 在性能和复杂工作流方面仍然存在一定的局限性。未来可能会出现一种更加适应大规模并行开发、全球分布式协作和高度自动化的版本控制系统。”
项目经理点头表示认可：“你说得对，随着开发需求的多样化，Git 也必须不断进化，才能保持其在开发中的核心地位。”
小李也意识到，尽管 Git 强大且灵活，但未来开发模式的变化无疑将推动版本控制系统的发展。基于人工智能和机器学习的自动化工具，可能会为 Git 提供更加智能的版本分析和优化建议，同时帮助开发者快速发现潜在问题，甚至自动修复常见的代码错误。未来的 Git，可能不仅仅是一个代码管理工具，它可能变成一个主动帮助开发者的智能平台。
随着 Kubernetes、Docker 等云原生技术的普及，团队的工作流程和开发环境也发生了巨大的变化。尤其是在微服务架构、容器化和云部署方面，Git 被赋予了新的角色。小李看到了 Git 与云原生技术结合的巨大潜力，开始思考如何将 Git 更好地融入到云原生的开发和部署流程中。
“小李，考虑到我们现在使用的 Kubernetes 和 Docker，如何将 Git 与这些工具结合，以便更好地支持我们在云环境中的开发和部署？” 项目经理提出了新的挑战。
小李微笑着回答：“Git 在云原生开发中的作用将变得越来越重要。它不仅可以用于代码管理和版本控制，还能与 CI/CD 工具和容器化管理平台如 Docker 和 Kubernetes 紧密集成。通过 Git，我们可以管理云原生应用的代码、配置和容器镜像的版本，并通过 Git 的工作流管理持续集成和交付。”
“能不能更具体地说说 Git 如何与这些工具集成？” 项目经理继续问。
“当然。我们可以通过 Git 来管理 Kubernetes 的 YAML 配置文件和 Dockerfile，每次提交都会自动更新这些文件并生成新的容器镜像。然后，我们可以将 Git 与 CI/CD 工具（如 Jenkins、GitLab CI 或 CircleCI）集成，让每次代码提交都触发自动化构建、测试和部署流程。当新的容器镜像构建完成后，Kubernetes 可以自动更新集群中的服务，确保所有服务运行的是最新版本的容器。” 小李解释道。
小李随后展示了如何将 Git、Docker 和 Kubernetes 融合在一起。他为团队配置了 GitLab CI，通过 GitLab 的 CI 管道，自动化地将每次提交的代码构建成 Docker 镜像，并将其推送到容器镜像仓库。然后，GitLab CI 会触发 Kubernetes 的滚动更新，将最新的容器镜像部署到集群中。
“这样一来，团队可以通过 Git 统一管理应用代码、容器镜像和配置文件，所有的操作都可以自动化完成，大大提升了开发和部署效率。” 小李补充道。
项目经理非常满意：“通过 Git、Docker 和 Kubernetes 的结合，我们能够实现更高效的开发和部署流程，这样我们的云原生应用管理会变得更加灵活和自动化。”
小李对 Git 的理解越来越深，他意识到，随着人工智能（AI）的发展，Git 与 AI 的结合将带来革命性的变化，尤其是在代码审查和质量保障方面。人工智能的智能化算法可以帮助自动化审查每次提交的代码，检测潜在的 bug、代码风格问题、甚至安全漏洞，从而进一步提高开发效率和代码质量。
“小李，你提到过 Git 可以与人工智能结合，我非常感兴趣。你认为 Git 和 AI 会如何结合呢？” 项目经理问道。
小李兴奋地回答：“未来 Git 可以与 AI 技术结合，自动化地分析每次提交的代码并提供反馈。比如，AI 可以通过机器学习算法分析代码的历史版本，识别出常见的代码问题、低效的代码结构和潜在的安全漏洞。每当开发者提交代码时，AI 会自动进行审查，甚至给出优化建议，帮助开发者提高代码质量。”
他继续解释：“AI 还可以根据项目的代码库和历史记录学习最佳实践，为每次提交提供个性化的建议。此外，AI 还可以通过分析大量的开源项目，帮助开发者学习其他项目的代码风格和技术实现，优化自己的代码。”
小李展示了如何将 Git 与 AI 集成，利用 GitHub Actions 和第三方 AI 插件，自动对每次提交的代码进行静态分析，检测潜在的 bug 和性能瓶颈。通过这种方式，开发者可以在代码提交之前获得实时的反馈，大大减少了错误的发生，并提高了代码的质量。
项目经理听后非常赞赏：“这个方案非常前沿，未来的 Git 不仅仅是一个版本控制工具，它还能成为智能的代码审查助手，主动帮助开发者提升代码质量。”
随着时间的推移，Git 不仅仅作为一个技术工具融入了团队的开发流程，也深刻影响了团队的文化。通过 Git，团队逐渐形成了一种透明、开放、协作的文化，所有的代码变更都能被追溯，团队成员之间的沟通变得更加顺畅。
“小李，最近我发现团队成员之间的沟通和协作变得更加高效了，大家在提交代码时，都在 commit message 中写得很清楚，代码审查时也能快速理解每个提交的目的和实现。” 项目经理总结道。
小李点头表示同意：“是的，Git 让我们的团队更透明。每个提交记录不仅仅是对代码的记录，也是对开发过程的记录。通过清晰的提交信息和 Pull Request，我们能够看到每个开发者的工作进展和思路，及时发现并解决问题。”
项目经理继续说道：“而且，Git 让我们保持了高效的协作，每个人都能在自己的分支上独立开发，只有经过审查和确认后，才会合并到主分支。这样我们不仅能保证代码质量，也避免了直接推送到主分支可能带来的风险。”
小李感慨道：“Git 让我们建立了一个高效、透明的开发文化，不仅提高了工作效率，还增强了团队之间的信任和合作。”
随着团队项目的不断发展，小李的思维也逐渐扩展到全球开源社区的协作。在一次技术分享会上，项目经理提到了一个新的发展方向：“小李，我们是否可以将我们的部分技术栈或工具开源，贡献给全球开发者社区，获得更多的反馈和贡献？”
小李顿时眼前一亮：“开源是一个很好的方式，可以通过全球社区的力量推动项目进步。同时，Git 本身就是开源的，已经深深融入了全球开发者的工作流。我们可以通过 GitHub 或 GitLab 等平台将我们的项目开源，让更多的人参与进来。”
“你说得对，开源不仅能促进技术创新，还能让我们获得来自全球的反馈。” 项目经理笑道，“那我们开始考虑如何将我们的项目开源吧。”
小李开始探索如何将团队开发的工具和库开源，并通过 Git 管理开源项目。首先，他为项目创建了一个 GitHub 仓库，并在仓库中提供了详细的文档、安装指南、功能说明等内容。接着，他将项目代码整理好，确保它能与其他开发者无缝集成。
在开源项目的管理过程中，小李使用 Git 的 Pull Request 工作流来管理外部贡献。当其他开发者提出修改或优化时，团队通过审查 Pull Request 来评估贡献质量，最终合并到主仓库中。这种流程帮助团队高效管理外部的贡献，同时确保代码质量和稳定性。
“小李，看到这些来自全球开发者的贡献，我们不仅提高了工具的质量，也扩大了团队的影响力。” 项目经理感叹道，“通过 Git 和开源，我们实现了全球范围的技术合作。”
小李也感到无比兴奋，他知道开源不仅是对技术的贡献，更是一种全球化的合作方式。通过 Git 管理的开源项目，他与全球开发者共同推动了技术的进步。
在一次团队会议中，随着 DevOps 实践的深入，小李意识到，随着自动化、人工智能和机器学习的引入，DevOps 也逐渐进入了智能化的新阶段。团队在原有的 CI/CD 管道上进一步优化，加入了智能化运维和持续交付（Continuous Delivery，CD）的理念。
“小李，现在我们已经将 CI/CD 集成到项目中，但如何进一步优化并提高运维的智能化水平呢？” 项目经理问道。
小李思索了一下，回答道：“我认为，我们可以通过将 AI 和机器学习引入到 DevOps 流程中，提升运维和发布的智能化水平。Git 可以与这些新技术结合，通过持续监控、数据分析和预测算法，帮助团队提前发现潜在的问题，甚至自动执行修复。”
他继续解释：“例如，我们可以通过 Git 与机器学习模型的结合，分析每次提交的代码，预测可能的性能瓶颈或代码错误。根据这些预测，CI/CD 管道可以提前生成优化建议，甚至自动修复代码中的常见问题。”
项目经理对这个思路非常感兴趣：“这个方向非常有前景。Git 不仅仅是管理版本的工具，未来它还可能成为我们 DevOps 2.0 中智能化运维的一部分。”
小李开始着手实现这一方案。他集成了 Git、Jenkins 和 AI 模型，通过分析每次提交的代码，预测潜在的性能问题和安全漏洞，并将预测结果通过 Git 提交记录反馈给开发者。当 Git 检测到潜在问题时，自动发出警告，并触发自动化修复任务。
“通过 Git 与 AI 的结合，我们的 DevOps 2.0 管道变得更加智能化，能够自动监控、分析和修复代码中的问题，减少了人工干预。” 小李兴奋地说道。
项目经理也非常满意：“这不仅能提高开发效率，还能让我们更早地发现并解决问题，减少了运维的负担。”
随着团队对自动化的需求增加，团队决定将自动化测试与 Git 完全集成，确保每次提交和部署都能通过自动化测试来保障代码质量。在过去的项目中，虽然有一些自动化测试，但由于没有与 Git 紧密结合，很多时候测试结果无法及时反馈给开发者，导致修复过程缓慢。
“小李，我们希望能够将自动化测试与 Git 完美集成，实现每次提交后自动执行单元测试，并将测试结果即时反馈给开发者。” 项目经理提出了新的需求。
“这个方案完全可以实现。” 小李回答道，“通过 Git 与 CI 工具的结合，我们可以在每次代码提交后自动触发测试脚本，确保代码的质量不受影响。同时，我们还可以将测试结果实时显示在 GitHub 或 GitLab 上，开发者可以第一时间看到自己的提交是否通过了测试。”
于是，小李开始配置 Git 与 Jenkins 和 Selenium 的集成。每次团队成员向 Git 提交代码时，Jenkins 会自动拉取代码并执行自动化测试，确保每个功能模块都经过严格的测试。测试结果会通过邮件或 Git 的通知功能反馈给开发者，确保开发者能及时修复问题。
“小李，这样一来，我们就能确保每次提交的代码都经过了自动化测试，不仅提高了代码质量，还能加快开发进程。” 项目经理满意地说道。
小李也意识到，Git 与自动化测试的结合将使开发流程更加高效和安全，减少了因人为错误或疏忽导致的问题。
随着公司逐渐迁移到云平台进行开发和部署，云平台成为了小李和团队工作流程中的重要部分。如何将 Git 与云平台无缝结合，成为了小李在这一阶段的新挑战。
“小李，我们已经在使用 AWS 和 Azure 进行开发和部署，但如何将 Git 与云平台更好地结合，形成一个高效的开发和部署流程？” 项目经理问道。
“我们可以通过 Git 与云平台的 DevOps 工具集成，来实现自动化构建、部署和监控。” 小李回答道，“例如，通过将 Git 与 AWS CodePipeline 或 Azure DevOps 集成，每次代码提交后，Git 会自动触发云平台的构建和部署流程。我们还可以通过云平台的监控工具实时获取应用的运行状态，确保代码始终在稳定的环境中运行。”
小李帮助团队配置了 AWS CodePipeline，并通过 GitHub 集成了自动构建和部署流程。每当团队成员提交代码时，AWS CodePipeline 会自动拉取代码、构建应用并部署到 AWS 上进行运行。通过云平台的监控工具，团队可以实时查看应用的健康状态，确保应用的稳定性。
“通过 Git 与云平台的集成，我们能够将开发和部署完全自动化，不仅减少了人工操作，还能实时监控应用的状态。” 小李总结道。
项目经理对这个集成方案表示高度满意：“这大大提高了我们团队的开发和部署效率，也让我们在云平台上的管理更加便捷。”
回顾这些年，小李的 Git 旅程不仅仅是一个技术学习的过程，它已经深刻地影响了团队的工作方式，推动了团队从传统开发模式走向 DevOps、AI 和云原生的未来。Git 不仅仅是一个版本控制工具，它已经演化为开发流程的核心，融入了团队的文化和协作方式。
“小李，你的努力让我们的团队在技术上不断创新，从自动化测试到云平台集成，Git 在我们的开发流程中扮演了越来越重要的角色。” 项目经理感慨道。
“Git 是我职业生涯中最重要的伙伴，它让我从一个新手开发者成长为今天的技术专家。未来我会继续学习，继续进步。” 小李自信地回答。
无论技术如何进化，Git 都将继续成为开发者的重要工具，帮助他们管理代码、提升协作效率、自动化工作流程。随着时代的变化，Git 也将继续为开发者提供强大的支持，成为他们永不止步的伙伴。
]]>使用场景是这样，在实际开发中，通常我们需要分别为开发和生产环境配置不同的服务和环境变量。虽然可以为每个环境维护独立的 Compose 文件，Docker Compose 提供了一个非常有用的特性，可以将多个 Compose 文件结合使用，简化配置管理。
默认情况下，Compose 会读取以下两个文件：
你还可以通过 -f 参数指定多个非默认的覆盖文件，Compose 会按顺序合并这些文件。
1 | docker compose -f docker-compose.yml -f dev.override.yml up |
1 | services: |
1 | services: |
在这个例子中，docker-compose.override.yml 覆盖了 docker-compose.yml 中的配置，添加了开发环境相关的文件挂载和环境变量设置。
docker-compose config 命令生成的配置）1 | name: "3" |
可以看到，通过合并配置，开发环境的调试模式和本地文件夹挂载已经成功加入了配置。
针对一些 lpk 规范目前无法覆盖到的运行权限需求， 可以通过 compose override 机制来间接实现。
通过应用查看器可以看到，这是 Docker Compose 配置的一部分，用于定义容器中的 containly 服务，并映射 playground 的 docker 引擎。具体的配置说明如下：
containly 是定义的一个服务名称。containly。create_host_path: true，意思是如果宿主机上的 /data/playground 目录不存在，它会自动创建。/data/playground 作为源路径，意味着宿主机上的这个目录将被挂载到容器内。source 目录映射到容器内部的 /lzcapp/run/playground 目录。容器内的应用可以访问这个目录。bind，表示采用绑定挂载方式
最后 highlight 下 WIKI 里的三句话：
lpk 中存在名为 compose.override.yml 的文件，并且内容是一个合法的 Compose 合并文件。/data/system/pkgm/run/$appid 目录，确认该目录下是否存在 override.yml 文件。lzc-docker-compose config 命令查看最终合并后的配置，确保它符合预期。子/data/system/pkgm/run/$appid 目录里，我的结果如下,供参考。
1 | docker compose config |
最开始我用 Squid 来代理 AWS VPC，后来想到懒猫也可以用作同样的功能。以下是我准备的 Compose 配置，我已经完成了 app 镜像的复制。
1 | services: |
下面是 Docker 截图：
默认安装后，Squid 的默认规则会屏蔽所有网站。若要访问内网地址，就会看到“访问被拒绝”的提示。接下来，我们需要修改转发规则。
进入 Squid 容器，编辑配置文件，然后重启容器即可生效：
1 | sudo vim /etc/squid/squid.conf |
现在就可以使用你喜欢的工具进行访问了。
然后就可以在外边访问私有地址了。
或者在终端上，通过设置环境变量以通过代理服务器访问 HTTP 和 HTTPS：
1 | export http_proxy=http://your_proxy_ip:3128 |
首先，创建一个包含你希望允许访问的域名的白名单文件。该文件会用于匹配允许的域名。
打开终端并创建白名单文件。例如，我们将其存放在 /etc/squid/whitelist 路径：
1 | sudo vim /etc/squid/whitelist |
在文件中，每行列出一个希望允许访问的域名。例如：
1 | .youtube.com |
这样就允许 youtube.com、bilibili.com 和 example.com 的请求通过代理，而其他未列出的域名将被拒绝。
squid.conf 配置文件接下来，编辑 Squid 的主配置文件 squid.conf，将白名单配置添加到文件中。
打开 Squid 配置文件：
1 | sudo vim /etc/squid/squid.conf |
在文件中，找到并添加以下规则：
允许 localhost 访问：
1 | http_access allow localhost |
该规则允许本地计算机（localhost）访问代理服务器。
添加白名单配置：
1 | acl whitelist dstdomain "/etc/squid/whitelist" |
这两行配置定义了一个名为 whitelist 的 ACL（访问控制列表），它从 /etc/squid/whitelist 文件中加载允许的域名。然后，我们允许匹配这些域名的请求。
拒绝所有其他访问：
1 | http_access deny all |
该规则确保只有白名单中的域名可以访问代理，其他所有请求都将被拒绝。
配置端口和缓存：
你可以在 squid.conf 文件中设置 Squid 的监听端口并配置缓存目录（如有需要）。例如：
1 | http_port 3128 |
其实 Docker 本身是 C/S 架构，只要配置好连接方式，就能在本地直接管理远程容器，甚至用 VS Code 图形化界面操作，完全不必反复登录。
下面我就用管理微服容器的例子，把实现方法和使用体验记录下来
为了避免奇怪的认证问题，可以先将 SSH Key 复制到远端，实现免密登录。
（/root 目录重启不会丢失 SSH Key）
1 | ssh-copy-id root@name.heiyu.space |
直接在本地设置 Docker 引擎的环境变量，指向远端的 docker.sock 文件：
1 | export DOCKER_HOST=ssh://root@name.heiyu.space |
在 Warp 中（非直接 SSH 登录），执行 docker ps 后，就可以看到远端的容器了。
不过仔细看，这里其实是系统组件，没有必要随便动，而且千万不要随便操作系统组件容器！
之前介绍过，playground 和 appstore 的 Docker 配置文件在其他目录。
这种情况下可以通过 docker context 引用非标准路径的 docker.sock：
1 | docker context create my-remote-sock \ |
playground 的 Docker 也可以用 Dockge 管理，不过当 Dockge 的功能不够用时，就可以用这个作为备用方案。
商店有时需要执行 lzc-docker exec 或 lzc-docker restart，可以先创建对应的 Context：
1 | docker context create lzc-remote-sock \ |
然后切换 Docker 引擎：
1 | docker context use lzc-remote-sock |
查看 Docker 信息：
1 | Kernel Version: 6.5.0-0.deb12.4-amd64 |
到这里，你会发现本地和远端几乎没有区别。
在 VS Code 中安装 Microsoft 官方 Docker 插件，即可在界面中查看远端的 Image、Container、Logs，并且可以直接 exec 进入容器。
在 Docker Context 面板可以直接切换上下文（相当于 docker context use lzc-remote-sock），然后就能在 VS Code 中操作对应容器和镜像，无需手动敲命令。
在命令行查看所有 Context：
1 | docker context ls |
输出示例：
1 | NAME DESCRIPTION DOCKER ENDPOINT |
通过 docker context 配合 VS Code Docker 插件，不仅能用命令行直接操作远端微服容器，还能图形化查看容器状态、镜像和日志。
这种方式的好处是：
对于习惯 GUI 操作的人来说，这几乎就是远程 Docker 的“丝滑”管理方式。下次维护微服时，你也可以试试这一套。
]]>半虚拟化（Paravirtualization）和全虚拟化（Full Virtualization）的主要区别在于 虚拟机是否知道自己“不是物理机” 以及 是否需要为虚拟化修改驱动或操作系统。
| 特性 | 全虚拟化（Full Virtualization） | 半虚拟化（Paravirtualization） |
|---|---|---|
| 客户机是否知道自己在虚拟环境 | 否，操作系统认为自己在裸机上运行 | 是，操作系统知道自己在虚拟机里 |
| 是否需要修改客户机操作系统 | 否（原始 OS 可直接运行） | 是（需要支持 paravirt 接口的内核或驱动） |
| 是否模拟完整硬件 | 是，完全模拟 CPU、BIOS、设备 | 否，使用简化接口与 hypervisor 通信 |
| 性能 | 一般略低（依赖 VT-x/AMD-V 等硬件加速） | 更高（减少陷入与上下文切换） |
| 示例 | VMware Workstation、QEMU + TCG、VirtualBox | Xen PV 模式、KVM virtio、Hyper-V Enlightenments |
| 是否支持热迁移 | 支持 | 支持 |
全虚拟化：通过软件模拟硬件，客户机无需修改即可运行，但性能相对较低，尤其是 I/O。
半虚拟化：使用专用接口与宿主机通信，需要驱动支持，性能更高。
进一步对比如下：
| 情境 | 全虚拟化 | 半虚拟化（virtio-net） |
|---|---|---|
| 客户机看到什么 | 模拟 Intel e1000 网卡 | 简化的 virtio-net 网卡 |
| 通信方式 | 模拟 PCI 总线、MMIO、DMA | 共享内存 + 通知机制（virtqueue） |
| 性能 | 中等（高 CPU 占用） | 高（低延迟、低 CPU 占用） |
| 兼容性 | 高（任何支持 e1000 的 OS 都能用） | 需要安装 virtIO 驱动 |
简而言之：
全虚拟化 = 模拟“骗操作系统”
半虚拟化 = 协作“告诉操作系统你在虚拟机里”
准备 ISO 镜像
virtio-win-0.1.266-1.iso）相当于安装的时候需要从 virtio 提取驱动文件来完成半虚拟化安装。
在 WebVirtCloud 设置中同时挂载两个 ISO
启动控制台进入安装界面
加载 virtIO 驱动
w10 目录下的驱动
正常分区并开始安装
安装过程，是漫长的等待。
首次启动时跳过联网
在系统内安装 guest tools
在 WebVirtCloud 下安装 Windows 时使用 virtIO，可以显著提升磁盘和网络性能，但前提是正确加载驱动并在系统中安装 guest tools。整个流程的关键点在于：
这样，你的 Windows 虚拟机不仅能正常运行，还能充分发挥 KVM 的 I/O 性能优势。
]]>使用官方安装脚本快速安装 Docker：
1 | curl -fsSL https://get.docker.com -o get-docker.sh |
设置 Docker 开机自启并立即启动：
1 | sudo systemctl enable --now docker |
docker 用户组（避免每次用 sudo）1 | sudo usermod -aG docker $USER |
1 | newgrp docker |
验证是否配置成功：
1 | docker info |
若无权限报错，则配置已生效。
我们将使用 Docker 的 host 网络模式挂载主机目录，确保 DDNS 能正常检测本地 IP：
1 | docker run -d --name ddns-go --restart=always --net=host -v /opt/ddns-go:/root jeessy/ddns-go |
/opt/ddns-go 是主机目录，你可以替换为任意路径，用于持久化配置。
启动后，DDNS-GO 的配置文件为 .ddns-go.yaml，位于挂载目录中。
部署完成后，打开浏览器访问：
1 | http://<Docker主机IP>:9876 |
你会看到 DDNS-GO 的初始化页面，如图所示：
DDNS-GO 是一个开源的动态域名更新工具，支持多个域名服务商，我的域名托管在 cloudflare 上，所以需要在 cloudflare 上申请一个 API-KEY 来做这个更新。
前往 Cloudflare 的 API Token 页面，为 DDNS-GO 创建一个具备修改 DNS 权限的 Token。
建议选择 “Edit zone DNS” 模板，只赋予必要权限，并可以限制在特定域名范围内使用。
此外，DDNS-GO 支持 webhook 通知，可选用如 Slack、Server 酱等方式实时通知 IP 变动情况。
我们尝试停止云主机后再重新开启，公网 IP 会发生变化：
重启后 DDNS-GO 会自动检测 IP 变动并更新域名解析：
通过域名访问服务仍然保持不变，无需手动更新 IP。
同时 Server 也会把这个消息推送到手机上：
即使云服务器没有绑定弹性公网 IP，借助 DDNS-GO 和 Docker，我们依然可以实现动态域名解析：
准确地说，需要在原域名注册商（我的是 AWS Route53）处修改 Name Server，将默认的 AWS NS 记录改为 Cloudflare 提供的 NS 地址。这样，域名解析权就转移到了 Cloudflare。Cloudflare 可以从懒猫微服的商店进入，也可以使用网页。而 DDNS-GO 使用商店快捷下载就非常方便。
Route53 中的 NS 修改界面 如下， 替换成 Cloudflare 的 NS 后，域名正式托管在 Cloudflare
前往 Cloudflare 的 API Token 页面，为 DDNS-GO 创建一个具备修改 DNS 权限的 Token。
建议选择 “Edit zone DNS” 模板，只赋予必要权限，并可以限制在特定域名范围内使用。
DDNS-GO 是一个开源的动态域名更新工具，支持多个域名服务商（不包括 AWS 的 Route53）。看来不仅迁移出来省钱，还省心。我们把上一步申请的 token 添加到这里，TTL 设置成自动就行。
此外，DDNS-GO 支持 webhook 通知，可选用如 Slack、Server 酱等方式实时通知 IP 变动情况。
我将 DDNS 记录绑定到家用公网 IP（IPv4），未启用 IPv6。保存配置后，前往 Cloudflare 后台查看 DNS 记录，已成功同步更新。
⚠️ 小提示：如果你绑定的 IP 是中国大陆的，建议不要开启 Cloudflare 的代理功能（小云朵），否则可能出现连接问题。
使用 Cloudflare 托管 DNS，访问你的网站时会根据规则加上 TLS 证书，实现 HTTPS 加密，非常方便省心。
通过将域名解析迁移到 Cloudflare，并配合 DDNS-GO 工具进行动态更新，既省钱又省事，还顺带获得了免费证书加持。相比 AWS Route53 的托管费用和配置复杂度，Cloudflare 无疑是个人用户和轻量级应用的更优选择。
]]>1 | python -m http.server |
1 | python -m http.server 1378 |
1 | python -m http.server 1378 --bind :: |
这些命令会在当前目录启动一个简单的 HTTP 文件服务器，方便快速共享文件或测试网页。
]]>Memos 是一款开源、极简、现代化的笔记系统，主打「快速记录、随时检索」。适合捕捉灵感、日常备忘、碎片想法、读书笔记等多种用途。
它具有以下特点：
目前 GitHub star 数已超 6k，开发活跃，文档完善，社区生态也在不断壮大。
Memos 主页面分为两栏：
展示所有 Memo 内容，以时间倒序排列
每条 Memo 支持：
#标签名 快捷方式）📷 示例页面如下：
在设置中可以启用 API 功能，系统会生成一个唯一的 API KEY，用于连接第三方客户端或自动化工具（如 Moe Memos）。
📷 API 开关和密钥生成页面如下：
App Store 上的 Moe Memos 是一款第三方移动端客户端，原生适配 Memos 的 API 接口，界面极简，使用流畅。
📷 图标预览：
https://memos.name.heiyu.space📷 登录后界面展示：
| 功能 | Flomo | Memos（自托管） |
|---|---|---|
| 微信同步 | ✅（原生） | ❌（可接 webhook 实现） |
| 多端支持 | ✅ | ✅ Moe Memos |
| 数据隐私 | ❌ 云端托管 | ✅ 完全自持 |
| 开放 API | ❌ 限制较多 | ✅ 支持 API KEY |
| 成本 | 收费会员制 | 免费开源（除托管成本） |
| Markdown | ❌ | ✅ 原生支持 |
| 图片粘贴上传 | ❌ | ✅ |
虽然 Memos 不支持微信原生同步，但凭借开放架构和高度可定制性，能实现更强的私有笔记体验。
Memos 是一款功能恰到好处、设计极简、部署门槛低的笔记系统，非常适合替代 Flomo 这类灵感记录工具。配合懒猫微服提供的部署方案，可以做到：
适合用来做「知识碎片记录」、「阅读随想」、「灵感管理」、「工程笔记」等场景。欢迎大家一起探索更多玩法！
]]>近期因 MacBook 系统降级重装，需重新部署 EasySearch 环境。由于系统未预装 Java，选择下载捆绑 JDK 的 EasySearch 版本，但在安装过程中遇到以下问题：
安全拦截
MacOS Gatekeeper 阻止运行捆绑的 JDK，即使在「系统偏好设置-安全性与隐私」中手动放行后，仍出现权限不足提示（见图 1）。
认证失效
配置文件中的密码校验异常，任何登录尝试均返回 401 状态码。
全局权限设置
首先通过终端命令关闭系统安全限制：
1 | sudo spctl --master-disable |
但发现此操作仍无法解决 JDK 运行问题。
最终解决方案
采用处理「App 损坏」报错的方法：
重新解压安装包
执行扩展属性清除命令：
1 | xattr -cr jdk/bin/java |
重新初始化 EasySearch
成功运行 EasySearch 并完成系统初始化（见图 3）。
MacOS 对未公证应用的限制日趋严格，建议：
xattr -cr命令可有效清除可能导致拦截的扩展属性https://www.elastic.co/cn/downloads/past-releases/filebeat-oss-7-10-2。
这主要还是 AWS 和 Elastic 公司之间的矛盾，AWS 托管的 ES 会和 Elastic 抢客户。所以 Elastic 搞了一个不能商业化的协议，影响了这个生态圈，也给开发者造成了很多不方便。
还记得这个非常戏剧性的 Issue：
https://github.com/elastic/beats/issues/8086
下面将介绍如何配置该版本 Filebeat 将日志发送到 Easysearch。
以下是完整的filebeat.yml配置示例：
1 | filebeat.inputs: |
setup.template 和 setup.ilm 相关的操作就是和没移除干净的 xpack 有关系，所以得再配置文件加上这些东西。
同时也得在 Easysearch 里面开启兼容 ES 的 API，不然会遇到这个报错。
在我的 MBP 上是这样：（config/easysearch.yml）
1 | discovery.type: single-node |
1 | sudo systemctl start filebeat |
1 | sudo systemctl status filebeat |
1 | echo "test log $(date)" | sudo tee -a /var/log/messages |
1 | GET filebeat-*/_search |
成功响应示例如下：
1 | { |
曾经在 ubuntu 上遇到过只要启动 filebeat 就报错一堆内存的信息：
这个文章给了一个解决办法：
https://infinilabs.cn/blog/2025/ubuntu_run_filebeat/通过以上配置和步骤，您应该能够成功使用Filebeat OSS 7.10.2 版本将日志收集到 Easysearch 中。
]]>
smb://[懒猫微服的IP地址或主机名]/[共享文件夹名称]。1 | smb://192.168.1.100/用户名/timemachine |
打开 **“系统设置” (System Settings)**（或旧版 macOS 中的“系统偏好设置”）。
点击 “通用” (General) > **“时间机器” (Time Machine)**。
点击 **“添加备份磁盘…” (Add Backup Disk…)**。
在弹出的列表中，你应该能看到你刚刚连接的 SMB 共享文件夹。
如果再次提示输入凭据，请再次输入你在懒猫微服上设置的用户名和密码。
Time Machine 会在共享中创建一个特殊的 .sparsebundle 文件，然后开始首次备份。
在某些情况下，macOS 的默认设置或某些第三方应用程序可能会导致 Time Machine 备份变慢。
1. 暂时禁用磁盘节流（Disk Throttling）
macOS 默认会对后台进程（包括 Time Machine）进行磁盘 I/O 节流，以确保系统响应速度。在首次备份或需要快速完成备份时，可以暂时禁用此节流。
bash sudo sysctl debug.lowpri_throttle_enabled=0 bash sudo sysctl debug.lowpri_throttle_enabled=1 
某些应用程序，特别是防病毒软件、系统清理工具或文件同步工具，可能会频繁访问磁盘，从而干扰 Time Machine 的正常运行。
3. 确保 Mac 保持唤醒状态
对于大型备份，如果 Mac 进入睡眠状态，可能会中断或减慢备份进程。
caffeinate 命令让 Mac 保持唤醒：1 | caffeinate -s -m -i -t 36000 & |
& 符号表示在后台运行。可以按到我目前磁盘使用了 90 个 G，在时间机器中看到占用 50G。
在懒猫网盘中也可以看到这个数据。
通过以上步骤，你就可以成功地将你的 Mac 通过 Time Machine 备份到懒猫微服提供的 SMB 共享了。
]]>
我的博客 RSS 订阅是：https://cloudsmithy.github.io/atom.xml
然后点击左上角的订阅管理，先新建一个分类，然后是输入 RSS 订阅地址即可。
我也添加了懒猫微服王总的博客订阅：https://manateelazycat.github.io/feed.xml
这个是我博客的订阅效果，这样在 PC 和移动端都可以访问了：
那如果想让用其他的软件订阅这个 FreshRSS 呢，在右上角点击设置，然后选择认证，点击允许 API 访问。然后就可以通过抓数据的方式进行访问。
然后回到账户管理，这个时候下面就出来了 API 管理这个选项，设置 token 然后就可以使用了。
然后我们访问 API 端点：https://freshrss.<机器名字>.heiyu.space/api/
这里可以看到 Google Reader compatible API 和 Fever compatible API。
1 | FreshRSS API endpoints |
那接下来使用 fluent-reader 订阅微服里的 FreshRSS。选择 Fever API，输入上边 RSS API 返回的 URL。
用户名和密码是登录 FreshRSS 的用户密码，然后端点是 Fever compatible API。（这里没有用到 token）
这个就是订阅的效果了。（FreshRSS 夹带私货自动订阅 release）
在 APP 里还挺好看的。（除了 fluent-reader 不支持检索）
用懒猫微服当作一个 RSS 存储的后端，同时也提供了一个 FreshRSS 的部署版本，很多记忆再也不会丢了。
]]>首先最直观的区别是软件客户端，像群晖，威联通的电脑版客户端是用来发现机器的 IP 地址的，然后后续所有的操作都在浏览器完成，比如新建用户，登录，审计，访问数据，查看监控。
而懒猫微服的所有操作几乎都在客户端完成，网页端更像是一个应用的 Dashboard。然后访问的时候使用域名，配合厂家的穿透服务，无论你是互联网访问还是局域网访问机器，用这一个地址就够了，不再需要在路由器上做端口转发，也基本可以告别自己搭建内网穿透的痛苦了。
还有一个非常主要的是社群，懒猫微服既有官方的大群交流技术，也有 VIP 的小群私人定制。大群里有各式各样的玩家，除了懒猫微服之外大家还会交流各种 Github 的开源项目，Linux 技巧以及电脑外设心得， 然后每天大家都贡献攻略。因为公司 base 在武汉嘛，当然也会有接地气的武汉风情。 VIP 小群会针对个性化的需要做一对一的指导，比如曾经帮我排查了家庭宽带 DNS 污染，UPS 信号干扰，甚至 OpenID Connect (OIDC) 的使用和接入等问题，对于开源软件部署在懒猫上有问题也是尽全力 额度支持，届时可以拉一个小会，然后共享屏幕给他们查看。可以放心的 show linux 命令和飙专业术语啥的。 很多的问题可以在半小时到一个小时就能解决，有时候甚至会更短。
不只是自己写的软件部署上去访问有延迟他们会帮忙排查，而且一些商店里社区用户贡献的开源软件的问题，他们也会帮忙查看并且给出一些解答方式。 毕竟开源软件的 issue 真的不少，他们不会叫你去开 issue 然后漫长的等待，他们会去帮忙追。
而传统 NAS 的社群主要靠的是爱好者自己发起和维护的，有问题在群里问可能最后没有讨论出结果就不了了之了。甚至很多时候都会纠结到底是选 Proxmox VE 还是 EXSI。对于攻略部分，大多是散落在资深用户的个人博客上，比如很多威联通的文章都会发在什么值得买上面。而对于提问能不能得到答案，完全取决于作者用爱发电的程度了。如果商业 NAS 提案例，那么响应时间可能要很久，如果你提简单的案例，那么可能立马有人给你打电话，如果是比较难的问题，可能最后就不了了之了。只能说在服务客户这方面亚马逊是在是开了一个很不好的头，大概是这样：
因为 AWS 负责运行、管理和控制从主机操作系统和虚拟层到服务运营所在设施的物理安全性的组件。客户负责管理来宾操作系统（包括更新和安全补丁）、其他相关应用程序软件以及 AWS 提供的安全组防火墙的配置。客户应该仔细考虑自己选择的服务，因为他们的责任取决于所使用的服务、，这些服务与其 IT 环境的集成以及适用的法律法规。责任共担还为客户提供了部署需要的灵活性和控制力。
所以有时候遇到两个产品交叉的问题，我们一般是很难得到方案，很有可能两方都说这涉及三方产品你需要找对方，我们不了解你这个三方产品，没办法给你方案。而对于三方玩家几乎是没有办法同时把两个产品的售后叫到一起的。无论你是开案例还是拉一个会议，这难度很大很大。
然后是系统层面的对比，懒猫微服是 基于 debian 优化一套系统，后来又开了 root 权限，所以基本 Linux 能做的事他都能做，更是出厂预置了 dockage，dozzle 这样方面调试 docker 的软件，基本属于开箱即用。甚至我们还能使用 Docker 打包自己的软件然后上架给其他玩家使用，甚至可以对其他人说；
我的懒猫微服教程是中文圈里非常优秀的实战指南。
我的开发/移植软件也有非常多的懒猫用户在使用。
而开源的 NAS 基本上大家只玩虚拟机和按照教程配置 Docker，几乎是没有包管理工具的，所以安装的软件很受限。 如果真的想移植应用，那个开发者文档也是不太好看。起码对于普通玩家是真的劝退了。
最后一点也就是很重要的一点，关于 APP 访问这块。在从互联网访问这边，传统 NAS 有一个很大的痛点。一个是移动端软件适配不好，还有就是服务多了端口都得自己记住。再加上路由器转发的端口，真的很难记住了。而懒猫微服在移动端和 PC 上的页面几乎是差不多的，所有操作几乎可以在 APP 内部完成。应用商店上架的应用大部分都是 https 的协议和 443 的端口。不用自己做加密同时以及免去了记忆软件信息烦恼，毕竟即使是专业玩家，也不想天天做服务器的运维工作。
普通用户图一个方便。专业用户图一个折腾，然后缺少的就是一个稳定的穿透和传输，精力有限不想自己维护一些底层的东西。买个懒猫微服差不多全能解决了。
我一直有一个愿望，写一本 NAS 的书，让技术融入到爱好者的生活，技术不是枯燥的理论，当我们遇到问题的时候，才能想清楚他们为什么这么设计。技术人永不为奴。
]]>它主要用于 身份认证（Authentication），而 OAuth 2.0 主要用于 授权（Authorization）。简单来说：
下面以我的懒猫 ENV 查看器为例，来讲解这个登录流程。
当你在应用处点击登录就会重定向到登录中心，我们通常管这个叫做身份提供商（IDP），如果是其他的软件有可能是 “使用 Google 登录” 或 “微信登录” 。
跳转到认证中心，一般都会提示你是否确认登录，某某应用将要获取登录的权限，查看你的信息。在懒猫微服里这直接点击 Grant Access 即可。在其他的 IDP 中，会让你输入账号密码登录，并同意授权该网站访问你的基本信息（如邮箱、昵称）。
当 IDP 验证完的身份后，返回一个 JWT（JSON Web Token），其中包含你的身份信息。当网站验证 JWT 后，确认你的身份，并让你登录成功。我们也可以在 jwt.io 和 jwt.ms 这个网站去做解码。
我解码了其中一个 token，我们可以看到里面的信息，可以看到加密算法，颁发机构，过期时间，用户信息什么的，
这个是一般登录的流程，比如首次用户名和密码登录成功之后会返回一个 JWT，然后后续把这个 JWT 当做 bear token 来请求后面的资源。我们的 OIDC 和这个原理类似，只不过稍微复杂一些。
在 OIDC 协议中，会遇到三种 Token: id_token, access_token 和 refresh_token。
Access Token 用于基于 Token 的认证模式，允许应用访问一个资源 API。用户认证授权成功后，Authing 会签发 Access Token 给应用。应用后面就带着这个** Access Token** 访问资源 API。
ID Token 相当于用户的身份凭证，开发者的前端访问后端接口时可以携带 ID Token，开发者服务器可以校验用户的 ID Token 以确定用户身份，验证通过后返回相关资源。
AccessToken 和 IdToken 都是 JWT，有效时间通常较短。通常用户在获取资源的时候需要携带 AccessToken，当 AccessToken 过期后，用户需要获取一个新的 AccessToken。
所以我们一般说的 JWT 就是 Access Token 的部分用于授权。而ID Token 用户标注用户信息，Refresh Token 用来续签 Access Token 。
在懒猫微服上使用 OIDC 有一个好处就是，不用在 IDP 上填写申请信息，在程序运行过程中可以直接注入相应的环境变量，这样我们直接用就可以了。相当于传统 IDP 需要填写应用名称，做分组控制而言，这个自动注入的 OIDC 开箱即用很方便。
一般是有这几个信息：
先说 ISSUER_URI，这个是 OIDC 的入口，其中.well-known/openid-configuration 里可以拿到各种 URL，算是 OIDC 的入口，即使环境变量中没给信息我们也可以在这里查看。比如用来校验 JWT 的 jwks_uri。
GET https://<微服域名>/sys/oauth/.well-known/openid-configuration 结果如下：
1 | { |
至于回调 URL，这个是需要自己设置的部分。可能由于开发习惯导致每个应用的回调 URL 不一样。相对于在 IDP 中填写信息，在懒猫微服的 lzc-manifest.yml 中加这么一行即可。也只有设置了 application.oidc_redirect_path 之后，才能使用 OIDC 相关的环境变量。
1 | application.oidc_redirect_path: /callback |
可以看看我的懒猫 ENV 查看器的设置。通过 oidc_redirect_path 设置回调地址，然后使用 environment 字段还这是需要的环境变量。
1 | lzc-sdk-version: 0.1 |
然后我们来看 OIDC 的几种授权模式。
| 应用类型 | 授权模式 |
|---|---|
| 有后端场景 | 授权码模式 |
| SPA，无后端 | 隐式模式 |
| 应安全存储密钥 | 密码模式 |
| 服务器之间 | Client Credentials |
这个是 Authing 推荐的选择方式，不过据我的经验来讲，就 Web 开发而言大多还是选择隐式授权的居多。看的出来懒猫的 OIDC 也是用的这种。
懒猫微服也是用的授权码模式, 所以跳转的时候我们抓浏览器请求会看到：
1 | https://url/callback?code=xxxx |
其实一个良好的 OIDC 流程是这样的：
当访问没有权限的路由的时候，在路由守卫中重定向到登录页面。
当用户登录的时候，跳转到对应的的 IDP 控制页面，然后输入用户凭证。这个时候会走 IDP 的认证。
认证之后会颁发一次性 code（授权码模式），如果是简单的密码模式，那么就会直接返回 Access Token，ID token 以及 refresh token。
使用授权码 code 换取 AccessToken、IdToken 以及 refresh token。授权码模式的好处是，把真正的令牌藏在后端交换，只暴露一次性 code，从而极大降低令牌泄露和被滥用的风险。
最后我们再用 AccessToken 来访问资源。
以上是基于懒猫的 OpenID Connect （OIDC）的理论讲解的部分，后面我们会进行实操，手把手创建可以接入 OIDC 的应用。
备注：关于部分 OIDC 的图文来自 Authing 文档。
]]>故障问题是，只有一边的耳机有声音，于是京东寄修，得到的答案是没问题，直接给我原反了。然后后台给我一个一张检测单（请记住这个，后面京东后台竟然把这个删了）
所谓京东的人给我打电话，是沈阳口音，然后听起来就是一点不懂技术的样子。说耳机是固件的 bug，然后直接把固件降级然后就好了。
然后我直接三连问：
口头说好找人看，然后耳机直接给寄回来了，没有任何后续。
京东 Apple 里的耳机检测图片，一看就很不专业，像是某种小店。一口一个有苹果官方的人员主场，一口一个不解决问题，怕不是外包 hhh
但是，寄回来的耳机仍然是一样的问题。再次申请售后是不予受理。理由是上一次检测没有问题，让我去 Apple 线下自行解决。从普通客服到专员，再到所谓的客服经理无一不如此。真是，体验简直太差。那就让我去 Apple 直营店打你们的脸吧。
去了 Apple 三里屯，检测确实有硬件问题，左耳机收音有问题，右耳机能隔着盒子放出来声音，于是给换新了。贴一下检测单。
然后继续去京东 battle，说 apple 给换新了，你们京东为啥检测不出来。然后仍然是不予受理，继续装死。然后默默的把之前检测没问题的单子给删除了。（最前面的一张）
这里的红框圈起来的部分，本来是原来那个检测单的，后来竟然给删了，销毁证据，京东你真行。
以后电子产品大件还怎么放心在京东买啊？
]]>本文延续前两篇，演示如何把一个已经在本地运行良好的 Docker Compose 应用打包并上架到懒猫微服应用商店。以 Milvus 为例，逐步拆解 Manifest 配置、路由映射、数据卷绑定以及镜像加速等关键环节，帮助大家快速完成移植。
在懒猫微服中，一个最小可用的应用包仅需两个文件：
| 文件 | 作用 |
|---|---|
lzc-build.yml | 描述打包流程及应用图标。简单应用只需指定 icon 即可。 |
lzc-manifest.yml | 定义应用元数据与服务编排，是移植的重点。 |
本文主要关注 lzc-manifest.yml 的编写。
lzc-manifest.yml 字段逐一解析现在有了懒猫应用查看器很方便，我们以商店里的 Milvus 的示例 Manifest 为例，并附带注释说明。
这个 lzc-mainfest.yml 解析是重点。主要是 subdomain，ingress，services 这几个字段。总体上还是延续了 Docker compose 的风格。
1 | lzc-sdk-version: "0.1" |
subdomainsubdomain 是应用程序上线的域名，例如上述配置上线后即为 https://milvus.<节点名>.heiyu.space。
routesroute 来做七层的 HTTP 转发，类似 Nginx 的反向代理。规则格式为 本地路径 = 目标 URL。在示例中，根路径 / 被转发到前端服务 attu 的 3000 端口。
URL 规则：服务名.包名.lzcapp:端口。（包名随意起）
- /=http://attu.in.zhaoj.milvus.lzcapp:3000/这里 attu 是服务名，端口是 3000，in.zhaoj.milvus 是包名。
ingress用于四层直通转发，适用于非 HTTP 协议（数据库、SSH 等）。示例将 Milvus 的 gRPC (19530) 与 HTTP (9091) 端口暴露给外部。
bindManifest 中的绑定路径以 /lzcapp/var 为前缀。发布后会被映射到宿主机的 /data/app/var/<package>，也算是为了简化程序移植和学习成本。和 Docker-compose 写绝对路径来说，这里的可移植性执行更好。
健康检查在这里不是必须的，因为打包的上架的时候服务会帮忙做这个事情。
docker-compose.yml 对照懒猫 Manifest 的 services 段几乎一一复刻了传统 Compose 配置，常用键均保持一致。以下列出了 Milvus 官方 docker-compose.yml，方便对照理解：
1 | version: "3.5" |
差异点主要体现在：
lzc-cli appstore copy-image <image> 把镜像同步到 registry.lazycat.cloud，解决国内网络拉取问题。ingress，不再使用 Compose 的 ports。healthcheck。一条命令即可完成镜像复制并输出新的仓库地址：
1 | lzc-cli appstore copy-image nginx (base) 13:15:36 |
将生成的地址替换到 Manifest 的 image 字段即可。
lzc-manifest.yml 描述了全部运行时需求，移植时优先完善此文件。routes 管理 HTTP，ingress 管理 TCP，二者配合即可覆盖绝大多数场景。/lzcapp/var 避免硬编码路径，便于跨节点迁移。lzc-cli appstore copy-image 自动同步到 LazyCat Registry，稳定又快速。至此，Milvus 的 Docker Compose 应用已成功移植到懒猫微服。更多进阶玩法，例如 OIDC、VNC 集成等，我们将在后续文章继续分享。
]]>其实在 macOS 13 Ventura 系统中，我们可以很轻松地把键位逻辑切换过来，让 F12 默认就是 F12，而音量调节则通过 Fn + F12 来实现。下面是详细操作步骤。
打开 **系统设置 (System Settings)**。
（屏幕左上角点苹果图标 → 系统设置）
在左侧列表里找到并点击 **键盘 (Keyboard)**。
在右侧找到 键盘快捷键… (Keyboard Shortcuts…) 按钮，点击进入。
在弹出的窗口中，往下拉到最下面，找到 **功能键 (Function Keys)**。
打开 “将 F1、F2 等键用作标准功能键” （Use F1, F2, etc. keys as standard function keys）开关。
这样一来，就能让 F12 回归它的本职工作，日常办公和开发都方便很多。
📌 结语：
几步设置，就能让你的 Mac 更顺手。如果你也因为 Fn+F12 而烦恼，不妨试试这个小技巧。
寻找过 Apple 支持，答案就是升级系统。Apple 的行政关系团队给我找了一个非常不靠谱的人，一问三不知，问她什么就是再转问工程团队，然后所有的事情都推第三方软件。然后行政关系团队陈某说对技术不做评价，然后一再坚持他们的人都是专业培训上岗的，然后坚持不换人，坚持不解决电脑问题来给客户扣不配合的帽子。
然后一直拖到过保。以前 iphone 接不到电话是这样，现在 Macbook 还是这样。
言归正传。Mac 刷机一般几种办法。
MacOS 降级我采用的是 U 盘装机。参考这个帖子
https://support.apple.com/zh-cn/101578
从 Apple Store 下载 OS，然后把 U 盘的 label 改成/Volumes/MyVolume，最后做随身碟
可以选择各个 MacOS 大版本的最后的 release。
烧录命令是：
1 | sudo /Applications/Install\ macOS\ Ventura.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume |
如果需要其他的系统，那么换一个版本号即可。
我的 23 年的 M2 Pro，当时出长的时候是 MacOS13 Ventura，所以当我想换回 MacOS12 的时候下载都报错。
如果直接安装还会报错：这个卷无法降级。（不理解这个操作，windows 的话随便格式化）
需要进入磁盘工具降级：
然后安装就可可以了，剩下就是漫长的等待。
从 Intel 黑苹果时代走过来的，结果白的还没黑的好用。。。。
]]>其他的软件体验不佳的点主要是：
Planka 算是解决了大部分的问题：
虽然这个页面不是很现代化风格，但是也不丑，页面响应速度很快。而其他软件大多臃肿体验不佳，要么就是延迟的很高耽误体验。
简介的 UI 和快速的响应很好的诠释了 less is more 的原则。
进入主页之后可以新建多个项目，算是一个隔离吧，虽然我目前也只是用到了一个。
每一个 Project 都能开好几个 board，这样就把不同类别的事情跟区分开了。
然后每个 board 上标注 Todo，Doing，Pending，Done，Deprecated 来确认事情的进度。有点白版卡片的那个味道了，不用自己像线下那种写贴纸来回移动，也不用再花费软件的订阅的费用。
这个是我和前端协作开发时候一起做的 Dashboard，当时在一起开发一个前后端分离的大语言模型的 APP。
只要给他新建一个用户就可以了，然后分给他某个面板的权限，然后就可以可以一起愉快的协作了。（前提给他安装了懒猫微服的客户端，分了 app 权限）
这个是面板的详细参数，可以把 task 分配给某个成员，然后也可以添加 task 描述，task 子任务拆解以及成员评论，拿来记录一些 change log 还是不错的，起码测试的一些过程可以随手记录在这里了。
Dashboard 功能还需要继续探索，比如计时，打标签一些的功能。
不过我目前用到的功能就这么多，也算能基本覆盖全部的场景了。
这个是我用 planka 来追踪关于懒猫微服的写作和上架应用的一些事情，真的帮助了我很多很多。
简单来讲，这个 devshell 其实就是在微服上打开了一个虚拟机环境，然后我们可以进去里面测试我们的命令。非要说技术实现，那就是 docker exec 了。只不过是做成了本地和微服之间同步的样子。
输入微服的名字/v2/_catalog，可以看到微服里面 Docker 仓库存放的镜像，debug.bridge 开头的就是 devshell 的 image。
1 | { |
在 lzc-build.yml 里定义了 devshell 的配置，这个的意思是就是安装 node 和 python 的环境，设置国内源，然后讲根目录转发到 5173，这个是 vue 的端口。所以我们可以推断，这个是一个 Vue+python 的全栈项目，所以我们可以开两个终端来进入 devshell，分别调试前后端。
1 | devshell: |
使用 lzc-cli project devshell -f 进入 devshell，可以看到这个使用了 registry.lazycat.cloud/lzc-cli/devshell 作为 base image，然后换源安装依赖。最后设置 setupscript 里面的 ENV。而 CMD [“sleep”, “infinity”]会让容器启动后执行sleep infinity` 命令，即无限休眠。目的是防止容器因没有前台进程而自动退出（保持容器处于“运行”状态）。
这里有个问题，如果你在 lzc-manifest.yml 里指定了 routes 也同样会生效。如果你要跑一些初始化脚本，可以在使用这两个办法
如果你偷懒在 lzc-build.yml 里 routes 的执行/api/=exec://3000,./lzcapp/pkg/cache/backend/run.sh，似乎也只能转发端口，不能运行脚本。
从日志看，也就是说还是安装了一个应用程序上去，只不过我们可以通过类似 ssh remote 的方式来动态调试。如果 APP 上架之后，能做的恐怕只有 lzc-docker exec 了。
1 | 跳过执行 buildscript |
我们可以看到文件夹的内容已经被同步过来了，我们可以实时同步开发机文件的创建和修改。不过目前和移动，重命名相关的同步有点小问题，具体表现为
相信这两个小问题修好也只是时间问题，当然也有 workaround。
从/data/app/cache/包名这个目录删除 devshell 文件夹之后，然后重新执行 lzc-cli project devshell -f ，这样工作区就被清理干净了。
1 | (base) lzcbox-029c588e /data/app/cache/cloud.lazycat.app.todolistpy # ls |
另外，我们再通过 ssh 进入/data/app 这个目录，有两个子文件夹，一个叫做 cache，一个叫做 var。 cache 就是我们这个 devshell 的工作区。var 就是数据持久化的目录。如果在这里新建一个目录，那么就可以在网盘里实时看到。
1 | /data/app/var/xu.deploy.lazycat-nav # touch test |
以上就是 devshell 的全部内容了，如果你需要借助微服的一些特性还进行开发，比如获取环境变量，OIDC 什么的，可以用这个方法来轻松调试。
]]>需要在lzc-manifest.yml定义 oidc_redirect_path 和 environment。
lzc-manifest.ymloidc_redirect_path 就是你的应用的回调地址，只有写了这个之后才能正确使用 OpenID Connect 的环境变量。
回调地址是按照应用而定的，有的是/callback，/oidc/callback 或者/oauth/callback。
1 | lzc-sdk-version: 0.1 |
定义了环境变量之后，我们就可以在代码中使用环境变量：
开机时一次性从环境变量读取懒猫微服的应用域名、OIDC 客户端 ID/密钥，以及授权、令牌、用户信息三个核心端点，并根据应用域名拼出默认 Redirect URI，从而把所有与 OpenID Connect 登录相关的敏感信息解耦。
这里的 callback 是应用的回调 URL，需要根据应用调整。
1 | LAZYCAT_BOX_DOMAIN = os.environ.get('LAZYCAT_BOX_DOMAIN') |
在用户访问 /login 时动态生成一对 PKCE 凭据（随机 code verifier 和其 SHA-256 派生的 code challenge），把 verifier 暂存进会话，再携带 challenge 等参数构造 OIDC 授权码请求，并将用户浏览器重定向到身份提供方完成安全登录；回调阶段可用 session 中的 code verifier 与返回的 code exchange 配合，防止授权码被劫持或重放，从而提升 OAuth 2.0/OIDC 的安全性。
1 | # ======= 生成 PKCE Code Verifier & Challenge ======= |
generate_pkce_pair()secrets.token_bytes(32) 随机生成 32 字节高强度随机数。base64.urlsafe_b64encode 再去掉尾部 = 得到 code verifier。=，得到 code challenge。(code_verifier, code_challenge)。/login 路由generate_pkce_pair() 生成并拿到 code_verifier 和 code_challenge。code_verifier 写入 Flask session，以便稍后在回调时校验。AUTH_ENDPOINT 形成认证 URL：response_type=code 采用授权码模式client_id、redirect_uri、scope 等常规 OIDC 参数code_challenge 与 code_challenge_method=S256 声明使用 PKCE(S256)redirect(auth_url) 将浏览器跳转到身份提供方进行登录 + 授权/callback 处理函数先从回调参数取出授权码，再用会话里的 code verifier 按 PKCE + 授权码模式向令牌端点换取 access token 和 ID token；成功后用 access token 调 /userinfo 获取用户资料，并把三者一起返回。如此既完成了 OAuth 2.0 的安全换码，又拿到了 OIDC 提供的登录身份信息，实现前后端分离的单点登录闭环。
1 |
|
code = request.args.get('code')
code（授权码）。code_verifier = session.get('code_verifier')
/login 时存进会话的 code verifier，准备用于 PKCE 校验。准备换取令牌的 HTTP POST 请求
1 | headers = {'Content-Type': 'application/x-www-form-urlencoded'} |
code_verifier 会被身份提供方与首跳收到的 code_challenge 做 SHA-256 对比，从而证明客户端的“持有者”身份，防止授权码被截获后被第三方滥用。token_resp = requests.post(TOKEN_ENDPOINT, data=data, headers=headers)
token_data = token_resp.json()
解析 JSON 响应。例如：
1 | { |
access_token = token_data.get('access_token')
id_token = token_data.get('id_token')获取用户信息
1 | userinfo_resp = requests.get( |
/userinfo 端点，拿到 JSON 形式的用户信息。返回聚合结果（此处直接返回给浏览器以便演示）
1 | return { |
在浏览器中可以看到这个登录跳转：
还是这个图，我们继续看这个流程：
拿到 code 之后可以就可以换到 Access token 和 ID Token 了，这个 code 只有一次有效，可以达到防重放的效果。当然这个只是 OIDC 的一个例子，在生产环境的 APP 中还需要做路由守卫以及 access 续签的操作。
app.secret_key 支持 Flask Session。generate_pkce_pair() 动态生成 code_verifier / code_challenge ；后者随登录请求携带，前者保存在 Session，回调时再带给 Token 端点，防止授权码被劫持。/：渲染首页（需自备 index.html）。/login：response_type=code，scope 含 openid profile email）；/callback：code 与 code_verifier；TOKEN_ENDPOINT 换取 access_token 和 id_token；access_token 调用 USERINFO_ENDPOINT 拿到用户信息；注意：生产环境应关闭
debug=True、使用 HTTPS、校验state参数防 CSRF，并妥善处理 Token 异常和错误分支。
1 | import os |
如果使用 authlib 是这样子的.通过 Authlib 把应用接入 OIDC：
启动时先从环境变量读取并校验客户端 ID、密钥及各端点；
随后注册 OIDC 客户端并自动启用 PKCE。
用户访问 /login 时，服务端生成 nonce 并调用 authorize_redirect() 将浏览器跳转到身份提供方登录，同时在会话里保存随机值；身份提供方完成认证后回调到 /callback，authorize_access_token() 会携带先前的 code 和 code verifier 去换取 access token / ID token，并用保存的 nonce 校验 ID Token 防止重放。
成功后解析得到的声明（用户信息）渲染或写入 Session，即可认为用户已登录。如此利用现成库把 PKCE、状态验证、ID Token 验签等安全细节都交给框架处理，只需少量代码就实现了安全的单点登录闭环。
1 | import os, secrets |
跨域问题（Cross-Origin）本质上是浏览器的同源策略（Same-Origin Policy, SOP）在发挥作用：
同源指“协议 + 域名（或 IP）+ 端口”三要素完全一致。只要三者有任何一个不同，就被视为跨域。
同源策略只在浏览器环境生效；后端服务之间（如服务器 A 请求服务器 B）并没有 SOP 的限制。
| 场景 | 描述 | 是否受限 |
|---|---|---|
fetch('https://api.foo.com') 从 https://www.bar.com 发出 | 协议、域名不同 | 受限 |
http://example.com:3000 调用 http://example.com:4000 | 端口不同 | 受限 |
⚠️ 用 Nginx/OpenResty 并不会“自动”解决 CORS。
- 你可以把前端请求代理到后端 API，使浏览器认为请求仍在同一域名下，达到“变同源”的效果。
- 或者直接在后端/代理层加 CORS 响应头，两种方式都可以。
懒猫微服的上使用的是 OpenResty，这是一个功能齐全的 Web 应用服务器，它集成了标准的 nginx core、大量第三方 nginx 模块以及它们的大部分外部依赖项。所以和 Nginx 的配置文件是通用的。
以我之前比赛做的项目为例，这个是 Nginx 作为网关，监听 80 端口，然后反向代理到 Next.js 和 Flask。
1 | services: |
而 Nginx 的配置文件如写，做七成的转发，把根路径转发到前端，/api 转发到后端。所以前端的 axios 请求等于访问的/api 这个端点，所以可以规避跨域的问题。
1 | server { |
其实对于懒猫微服的 OpenResty 的也是一样的，好处是不用自己再找 base image 了，直接把配置文件写进去就能用了。
1 | lzc-sdk-version: "0.1" |
flask 的 image 是我之前做的一个镜像仓库docker run -p 5005:5000 cloudsmithy/flask-demo:latest
然后通过lzc-cli appstore copy-image cloudsmithy/flask-demo 把镜像换成懒猫的镜像，registry.lazycat.cloud/u04123229/cloudsmithy/flask-demo:c14689303facd82c
通过setup_script传入和 Nginx 类似的配置文件，原理是替换 docker image 本身的 entrypoint/command 参数。
1 | # 打包成 LPK |
我们可以看到这个是 OpenResty 的主页，然后访问https://app-proxy-test.micro.heiyu.space/api/ 也能返回 Flask 容器“Hello from multi-arch Flask Docker in production mode!”。
如果你想把根路由直接代理到容器，也可以使用这个办法。这个一般是用来做反向代理来访问内网的服务，即使是 http 也没有关系。这个环境变量应该是懒猫魔改的快捷方式。不要和配置文件混用。
1 | lzc-sdk-version: "0.1" |
有时候还会加上BASIC_AUTH_HEADER这个字段来让 nginx/Openresty 自动填写密码，除了你的容器以外，代理外边服务也行。
其实用echo -n "user:password" | base64,的数据来填充BASIC_AUTH_HEADER“Basic
1 | lzc-sdk-version: "0.1" |
另外也支持多域名解析，这个在传统的线下机房比较常见，而云上基本上还是 7 层基于路由转发，比如第一种，我也更加熟悉第一种。
这个其实就是加了一个 secondary_domains 的字段，然后把后端单独暴露出来了。这样就子域名就可以访问后端。
1 | lzc-sdk-version: "0.1" |
打开官网
我们本次实验使用的是国内站点，部署在阿里云，目前可以免费使用。
选择 手机号码 或 邮箱 登录/注册。
进入控制台首页后，点击 Create Cluster 按钮。
在弹窗中选择 Free Tier（免费套餐），数据中心默认为 阿里云 · 杭州。
等待几分钟，集群创建完成后会显示 Endpoint URI、API Token、Cluster ID 等信息，请妥善保存。
运行中
安装 milvus-cli：
1 | pip install uv |
终端执行 milvus_cli，进入交互式 CLI
1 | milvus_cli |
1 | uv venv milvus-py --python 3.12 |
如果你使用的是 conda 也可以：
1 | conda create -n milvus-py python==3.12 -y |
1 | git clone https://github.com/zilliztech/cloud-vectordb-examples.git |
1 | pip3 install pymilvus==2.5.3 |
1 | cd cloud-vectordb-examples/python |
需要注意的是，在开源版本的 Milvus 中，端口号是 9530 / 9091 ，而在 Zilliz cloud 上，端口上是 443.
1 | import configparser |
在 config.ini 中填入你的集群信息（务必保持格式），⚠️ 切勿把 API Key 提交到公开仓库。
1 | uri = https://<your-endpoint> |
1 | python3 hello_zilliz_vectordb.py |
运行后可见类似输出：
1 | Connected to DB: https://in03-d7b5690fee7bcbf.serverless.ali-cn-hangzhou.cloud.zilliz.com.cn successfully |
如果控制台显示如上日志，即表明已成功连接集群、创建 collection 并完成简单的向量检索。
然后我们就可以通过控制台来查看这个新建的索引和数据了。
除此之外，zilliz 还提供了 restapi ，这样我们就可以通过请求 HTTP 来完成数据检索了。
1 | curl --request POST \ |
Python 版本的如下，需要我们把 api-key 作为 bear token 传到请求头里。
1 | import requests |
同样我们再 Postman 上也可以进行测试，需要注意的是，即使请求体是空的，那么也需要使用 {} 来占位。
在左侧的 api-playground 中，我们可以看到更多的 API 操作，同时还可以直接在浏览器上发送请求。
通过 Zilliz Cloud，我们可以在几分钟内获得一套托管版 Milvus 服务，免去本地运维与资源成本，非常适合作为学习、原型开发或小型应用的向量数据库后端。祝大家玩得开心！
]]>主要还是特意找问当地的小伙伴要了攻略：
推荐的专门吃东西的几条街是玫瑰街、粮道街、万松园、吉庆街这些。早餐小吃比较丰富，武汉的早餐文化特别浓厚，早餐种类特别丰富，很多碳水炸弹。
正餐可以考虑 来菜，是湖北菜，藕汤是湖北菜最具特色的。文章中下面的信息还是可靠的。
午餐：这个季节湖北的藕汤已经上市，基本上随便一家都很好喝，一定要选筒子骨藕汤，9 孔粉藕炖的那种。怕踩坑可以选一些连锁的，出品有保障，如刘胖子、老村长、艳阳天，不怕排队也可以去夏氏砂锅。
武汉魅族魅友家：https://weibo.com/2709494027/4973440665388967 这是小伙伴自己总结的
武汉推崇藕汤一定要用粉藕，有炒菜的那种，也可以点干煸藕丝，那就是不同的味道了
江汉路的风景不错，虽然是老城区，住宿条件差强人意。但总归风景和视野还是不错的，可以远眺长江，夜景也很美，楼下就是江汉路步行街。
携程上酒店骂声一片，都是吐槽住宿添加太差的。如果介意的话可以选择住对面的武昌。去的时候爆满，其他地区送早餐给升级房间的桔子水晶都没有增值服务了。
早上的江汉路是没什么人的，不过晚上到 12 点都很热闹。每天都是拖着走废的腿一瘸一拐的走回去的，青城山崴的脚，再经历重庆摧残，最后在武汉彻底残了。
武汉没有真正的市中心的概念，基本都是一个片区一个片区这样的。武汉本来就是三个城市合并来的，武昌重政治、汉口重经济、汉阳重工业。所以景区或者玩的地方相对也都比较分散。
早餐可以选严老幺的三鲜豆皮和黑色麻将的热干面。那个新出的三鲜面就不要点了，毕竟不是苏州，三鲜面很难吃！！！
现做的三鲜豆皮，很多人排队，一定要现做现吃才好，这样外壳才是脆的。
山海关路来过个不早的早，每个人拿一个小板凳，5 块钱的热干面，三块钱的藕粉汤，基本早上就吃饱了。
第二天还是骑车到山海关路继续喝了藕汤，这家叫做金三角吊子煨汤。20 块钱一碗，有排骨有莲藕，总体来说比来菜吃的爽一点吧。算是在武汉吃到的第一个拉丝的藕。
山海关路也吃了三鲜豆皮，和毛氏汽水包。不过是在吃不下了，据说这家牛肉面也不错。嗯，来自襄阳。
这个是小伙伴的旅游攻略：
1、黄鹤楼，现在应该在准备春晚分会场，闭园了
2、东湖有空可以看看，东湖绿道、或者磨山风景区也可以锻炼一下，都在东湖片区，哈哈
3、湖北省省博物馆离东湖也很近。越王勾践剑、曾侯乙编钟是镇馆之宝。
4、武汉大学凌波门不用去了，日出日落这个季节都不太合适。武大校园里面还行，建筑风格也很不错。
5、宝通寺、古德寺、归元寺是寺庙，长春观是道观。
6、黎黄陂路、昙华林是文艺青年打卡地。黎黄陂路有很多近代风格的建筑，适合拍照。昙华林有一些文创小礼品吧。
7、江汉路、楚河汉街、武商梦时代是商圈。江汉路建筑风格是近代租界风格，距离江滩近。楚河汉街有新开的 SKP，奢侈品应该相对多一些。武商梦时代是亚洲最大的单体商场。
武汉博物馆真的很大，需要留一天的时间来看。越王勾践剑需要排队很久。
沿着东湖骑车，慢慢就天黑了，然后发现自己在湖中央凌乱。武大不让进，所以一路都在怀疑自己，一个人在外地，大晚上在人少的地方骑车干嘛。
武汉玩的地方，可以考虑下湖北省博物馆，越王勾践剑和曾侯乙编钟（有时候会有编钟表演）。
东湖也还不错，比较大，春天有樱园，也可以在那边露营。这个季节不是特别推荐，风应该会比较大
江汉路步行街是商圈，仅临武汉江滩。江滩晚上可以看对岸的楼宇和大桥上的灯光表演，比较类似上次在杭州游船的风景
从东湖离开已经是这个点了。
在楚河汉街，基本是本老武汉强行拉倒店里。说没有预制菜，藕汤保拉丝。于是大众点评 L6 送了一个价值 60+的藕汤，然后点了一个干煸藕丝。算是在武汉吃的性价比最高的一顿。果然，大众点评高等级在哪里都吃香。不过后来朋友去，据说是是不再送了。
干煸藕丝很酥脆，虽然说干炸的牛肉不多，但是味道简直无可挑剔。不过一个人吃俩大菜是在是太撑了，还是得找个女朋友一起才好。
第二天又去了梨园。下午的东湖，美的不可方物。（没坐船，来回要七八十，而且要跟着船马上回来）
美的像一幅画。
晚上去的夏氏砂锅，因为谈季加上人少，所以基本没排队。
冬天点着炉火，喝着热气腾腾的藕汤，从上暖到下，还有这个藕是真拉丝呀～
徒步横跨长江大桥，属于又菜又还玩，危险指数 4 颗星，车在走桥在晃，小哥自行车在眼前飘过。
用 Apple Watch 记录下这个过程。
春晚彩排的原因，黄鹤楼进不去。只能在外边听见 1234567 的敲鼓声音，不过很多人也说黄鹤楼在外边看看就好了。
文人的名楼情节，大概是拜崔颢的诗词所赐了。
最后一天来参观国民政府办公厅，现在的南阳大楼被改成了酒店还是饭店一类的场所，只有三楼对外开放。电视剧里的政府办公厅和这个很像。
请看大图 VCR：
还有江汉关博物馆的讲诉曾经的故事，近代的条约，租借等等。。。。
江汉路以及黎黄坡路的租借都改成了经典或者银行，但是我们仍然可以看到过去的岁月。
那，南京得什么样啊？
临走之前吃了，王记牛杂，生滚牛肉热干面，真心不错。
回去写了三天四藕小记：
如果用藕来比作爱情，来菜是初相识，幻想最初的美好，该是粉糯入口即化如亲吻红唇，而非迎合大众变节故作搔首，又道是重口难调。再三思虑下，你终究不是我的头牌。出来乍到幻想要轰轰烈烈的爱情，一次次的修改已不愿再等。
老武汉是路边的艳遇，你听我诉着苦， 又抚着上次的伤口，于是急切的来一场试探性的邀约，再经历试探，喧闹，繁华过后，你把新唤作老。清炖，油炸样样拉丝。本已无可挑剔，可惜你在灯红酒绿，不能常常如愿。
小吃街是日常，简单不精致，朴华粗糙，藕形状不一，大口啃着才舒服，细小的渣碎弃之不要。调侃着来往的路人以及同桌的游客，看着提高嗓门吆喝的店家。同时还能大快朵颐享受着放松而自在的瞬间，虽无钟鸣鼎食，处处诉说着平平淡淡。
夏氏的砂锅是醇厚的，就着炉火，半暗的灯光下，乘上一晚热气腾腾的汤，软糯的藕配着油花花的汤，可以散去一整天的疲惫，这家拉丝也是最多的，点着炉火，就好像无论多晚多累总归有人懂你，等你。汤一定要微烫入口，否则要重新加热到沸腾才行，锅气才是真实的人间烟火。
而且个人谷歌账号登录就能免费用！
免费额度为每分钟 60 次请求、每天 1000 次请求，是业内最高的免费额度，几乎不会遇到限制。
先来安装 gemini-cli，其实就是一个 NPM 包。
1 | npm install -g @google/gemini-cli |
如果不出意外的话，执行之后会闪退。网上说需要设置 TUN 代理，甚至连命令行 export 环境变量也不行。
然后登录 Google SSO 验证，页面会显示 Gemini Code Assist 已获得访问您账号的授权。但是其实还是不行。我们继续看。
命令行还是会得到这个报错：
网上基本有这个教程：
用过谷歌云或者 ai studio 的，使用 gemini cli 登陆时可能会有些麻烦，可能要打开 console.cloud.google.com，找到你的 project id，然后设置 GOOGLE_CLOUD_PROJECT 环境变量，使用这种方式打开 gemini cli，就可以用了
然后执行这句，这是环境变量。(临时设置, 仅当前会话有效）
1 | export GOOGLE_CLOUD_PROJECT="your-project-id" |
如果你想让这个永久生效的话：
1 | echo 'export GOOGLE_CLOUD_PROJECT="your-project-id"' >> ~/.zshrc |
然后 source ～/.zshrc 就可以了。
有发现新的错，
1 | [API Error: [{ |
打开报错了的网页 https://console.developers.google.com/apis/api/cloudaicompanion.googleapis.com/overview?project=xxxxxx，比如这个，这个网页是和你的 ID 相关的，然后点击启用。
终于可以用了不容易。
官网给出的示例里只有 3 个必备文件：lzc-build.yml、lzc-icon.png、lzc-manifest.yml。
lzc-icon.png**：应用图标，必须为 PNG。lzc-build.yml**：定义打包脚本、输出路径与图标路径。lzc-manifest.yml**：应用清单，描述路由规则等。lzc-build.yml 示例1 | # 打包预处理，例子里是复制目录，打包前端文件 |
build.sh 执行完后目录结构大致如下：
lzc-manifest.yml 示例1 | lzc-sdk-version: 0.1 |
routes 这里有三种写法：
http(s)://$hostname/$path， 这个是我们印象里的网关代理后端服务，比如/api/=http(s)://$hostname/$path，其实就类似 Nginx 的 proxy_pass 将/api 转发到 http(s)://$hostname/$path/。附上 pip 多源的例子：
1 | # 已有 —— 主索引 & 前两级备用 |
1 | # 打包成 LPK |
然后是打包，如果缺少 lzc-build.yml，lzc-icon.png，lzc-manifest.yml 三者之一就会报错。
LPK 是懒猫微服应用商店 APP 的安装包格式，其实可以理解为一个配置文件的压缩包，安装之后其实就是在微服内部启动了一个 alpine 的 image，然后通过 build.sh 安装依赖。
通过 lzc-docker 来看，直接打包的就是这个 images registry.lazycat.cloud/lzc/lzcapp:3.20.3
命令如下lzc-docker history –no-trunc registry.lazycat.cloud/lzc/lzcapp:3.20.3，能够看到是 Alpine 作为 base image，然后更换中科大的源，以及安装 gcompat 以兼容 glibc 程序。
1 | (base) lzcbox-029c588e ~ # lzc-docker history --no-trunc registry.lazycat.cloud/lzc/lzcapp:3.20.3 |
甚至可以看到，这个 image 是连 bash 以及各种开发运行时都没有的。
1 | (base) lzcbox-029c588e ~ # lzc-docker run -it registry.lazycat.cloud/lzc/lzcapp:3.20.3 bash |
所以这个 backend 文件夹的 run.sh 是拿来安装 Python 依赖的。而前端是使用本地的 npm 打包的。
1 | #!/bin/sh |
安装之后的 app 可以通过 lzc-docker 查看，也可以使用 Dozze 查看日志，一般 debug 时候的时候会看这个。
DOZZL 需要安装开发者工具，然后使用https://dev.设备名.heiyu.space/dozzle/访问。
一般来说部署有两个 pod，一个是 App-1 结尾的，主要是涉及到转发，run.sh 自动安装依赖，以及健康检查。
1 | PATH:"/" is served by "file"://"/lzcapp/pkg/content/dist" |
应用名字-1 结尾的，这个才是应用的日志。
1 | [2025-06-29 17:29:29 +0800] [1] [INFO] Starting gunicorn 23.0.0 |
希望大家都能够多多为懒猫微服贡献应用。
]]>作用：用于通过第三方客户端（如 Python 的 smtplib）发送邮件，避免直接暴露邮箱登录密码。
获取方式（以 163 邮箱为例）：
登录 163 邮箱。
进入 设置 → POP3/SMTP/IMAP。
开启 SMTP 服务，系统会提示你设置授权码（类似 ABCDEFG123456，不是你的登录密码）。
复制这个授权码，替换代码中的 your_authorization_code。
1 | import smtplib |
网盘的挂载是支持了 WebDAV 和 Sambda。这是常见的两种远程访问的协议。
WebDAV（Web Distributed Authoring and Versioning）主要用于 HTTP/HTTPS 协议 的文件共享，适合 远程访问、云存储。基于 HTTP/HTTPS，可在浏览器中直接访问（如 http://server/webdav）。
SMB（Server Message Block）/ Samba 主要用于 局域网文件共享（如 Windows 共享文件夹、NAS、企业内网存储）。
通过 mount 命令可以看到，懒猫微服客户端默认使用的是 SMB 协议挂载：
1 | //xu-automount@file.micro.heiyu.space/xu-automount on /Users/xu/lazycat_automount/micro (smbfs, nodev, nosuid, mounted by xu) |
默认有两个文件夹，其实都是指向网盘根目录的软连接。两者内容完全一样。
<用户名>-automount：这个应该不是自动挂载到文件管理器的目录
<用户名>: 这个是网盘多租户的目录
所以在 Steam 里我们直接添加驱动器就好：
然后可以选择这两个文件目录，就像前面介绍的，这两个选择哪个都行：
然后这个时候会弹出来这个提示。我们选择允许。这样 Steam 才能有写入懒猫网盘的权限。
然后选择下载之后，我们发现网盘里多了一个 SteamLibrary 的目录。所有的游戏都存在这里。
如果你比较习惯网盘的页面，也可以在网盘里找到 SteamLibrary 的目录
如果哪天不再需要写入懒猫网盘，用这个办法删除。网上吐槽挺多的。
从懒猫微服应用商店搜索 Console，点击“安装”即可：
初始化之后登录：
首次登录后台，左侧侧边栏包含 Dashboard、Agents、Settings 等模块：
ES 的话，我是直接用 Dockge 安装的，如果你需要啥中间价，数据库都可以用这个安装。
前提需要用 lzc-cli appstore copy-image 来获取国内的镜像源：
1 | # 将官方镜像复制到懒猫内网仓库 |
然后把 docker run 或 docker-compose.yml 中的镜像地址替换成上一步生成的私有 registry 地址即可。全部容器由 Dockge 图形化管理：
（截图信息要点）
Running。
| 需求 | 懒猫微服能力 | 体验亮点 |
|---|---|---|
| 24 × 7 在线 | 独立云主机，自动重启、监控告警 | 关掉本地电脑，服务仍在运行 |
| x86 架构 | 后端统一使用 x86 节点 | 对 Mac M 系列（ARM）用户，可避免本地编译兼容性问题 |
| 多端远程开发 | 内置 Web Shell、端口映射、域名分配 | VS Code Remote / JetBrains Gateway 秒连接 |
| 镜像同步 | lzc-cli appstore copy-image | 国内网络下拉镜像不超时 |
| 中间件生态 | Dockge + Compose | RabbitMQ、Redis、Postgres 都能一键启动 |
| 环境变量管理 | UI + .env 托管 | 私密信息集中维护，避免泄漏 |
总结下来，把懒猫微服当作一个可远程访问的轻量开发机还是挺合适的：
适合：
👉 想要随时随地调试项目的开发者
👉 不想在本地装一堆环境的轻量用户
👉 有多端共享、协作需求的远程开发场景
整套流程走下来，你只需一台浏览器，就能获得 24 × 7 不关机的云端开发环境。如果你也是 Mac M-芯片用户、经常出差或需要多端协作，不妨试试用懒猫微服托管自己的 DevBox。
]]>index.number_of_shards）一旦创建就无法直接修改。这给实际使用带来挑战：本文将带你深入了解三种常见但本质不同的索引重构方式：split、shrink、reindex，教你如何选择合适方案、安全操作，并解释为什么split + shrink 无法取代 reindex。
| 方法 | 是否重建索引 | 可否原名使用 | 改分片数限制 | 是否保留数据 | 是否改结构（mapping/settings） | 常见用途 |
|---|---|---|---|---|---|---|
split | ✅ 新建索引 | ❌ 不支持 | 只能 × 倍数（如 1→2→4） | ✅ 是 | ❌ 否 | 提升写入并发/读性能 |
shrink | ✅ 新建索引 | ❌ 不支持 | 只能 ÷ 因数（如 4→2→1） | ✅ 是 | ❌ 否 | 合并历史数据分片 |
reindex | ✅ 新建索引 | ✅ 支持（先删） | 任意 | ✅ 是 | ✅ 支持 | 自定义结构/分片/升级 |
适用于： 提升并发能力、增加查询/写入并行度。
index.blocks.write: true（只读）；主要是防止写入继续增长。1 | # 设置只读 |
1 | POST /abc/_split/abc_split_2shards |
执行结果如下：
1 | { |
如果不是倍数也会报错：
1 | { |
查看索引的信息：
1 | GET /abc_split_2shards/_settings?flat_settings=true |
/_settings：Elasticsearch 提供的 API 端点，用于查看索引设置。
?flat_settings=true：查询参数，使返回结果以扁平化的键值对形式展示（而非嵌套结构）。
可以看到目标的索引也是只读的，这在 Easysearch 里是 ElasticSearch 不一样的地方。
1 | { |
然后使用这个来解锁 write block。
1 | PUT /abc_split_2shards/_settings |
如果你不想让目标索引变成只读。也可以在_split 的时候加上 “index.blocks.write”: false。
1 | POST /abc_split_2sharxds/_split/qwe |
适用于： 历史归档数据压缩、节省内存、提升查询效率。
1 | # 强制所有主分片调度到 node-1 |
1 | POST /source_index/_shrink/source_index_1 |
1 | PUT /source_index_1/_settings |
适用于： 任意修改分片数、字段结构、settings，或实现“看起来改了原索引”的效果。
1 | # 1. 创建临时索引结构（你想要的新结构） |
很多用户会问：能不能 shrink → split 或 split → shrink 拼接出任意分片数？
答案是：数学上不成立 + 实战限制太多。
| 操作 | 说明 |
|---|---|
| split 只能倍增 | 例如：1 → 2 → 4 → 8 ✅，但不能变成 3、5、6 ❌ |
| shrink 只能整除 | 例如：8 → 4 → 2 → 1 ✅，但不能变成 3、5 ❌ |
| 二者组合 | 受限于倍数 × 因数关系，不是万能变换（大多数目标分片数根本到不了） |
reindex可以任意：
| 场景 | 推荐方式 | 理由 |
|---|---|---|
| 写入并发不足（1 → 4） | split | 快速、低风险 |
| 存储/查询优化（8 → 1） | shrink | 节省资源、适合归档 |
| 修改索引结构、字段、settings | reindex | 最灵活、唯一支持任意结构 |
| 想保留原名但改分片数 | reindex（配合 delete/recreate） | 只有它能实现 |
| 不想中断服务 | reindex + alias 切换 | alias 实现无缝替换 |
S* split/shrink 一般用于 线上小范围结构调整；
一般是需要用其他的 IDP 作为测试环境，因为 OIDC 的协议是通用的，不像 OAuth 这么百花齐放。
以我的“家庭任务通知”APP 为例，讲解下在开发模式下接入懒猫微服的 OpenID Connect (OIDC)。
首先前端需要有一个 OIDC 的登录按钮，然后做好 OIDC 的逻辑：
从应用商店安装我写的“懒猫 ENV 查看器”，导出 env.example 文件，导出项目之后重命名为 .env。这样就可以把商店里的 ENV 复制到本地的开发环境。
不过需要注意的是：应用名字和回调函数还是原来的，不要轻易去改。遇到问题再手动调试。
https://appstore.lazycat.cloud/#/shop/detail/xu.deploy.env
登录之后我们就看到了这个页面：
点击“授予权限”，会报错。这个是由于回调 URL 不匹配的问题，还是会访问 ENV 查看器的 URL：
然后我们手动把上边的 URL 改成我们自己的回调路由就可以了，如果想自动化，你也可以写一个油猴脚本。
这样就可以完成本地的 OIDC 授权流程啦。开发的时候不用搭 IDP，也能走懒猫的登录流程。是不是很方便？
]]>用了 Apple 的原装线连接 pocket3 和 iPhone 结果没反应，但是在 IPAD 上就能够成正常连接。
然后换了移动硬盘连接 IPhone 同样也不行，和 IPhone 的售后 battle 了好久对方也说不明白。最后还是 Apple 论坛上找找到一个帖子，
Lighting 原生不支持 OTG，还得买转接头，这算盘打的真响。
最后感谢欧盟，要求 Apple 更换 Typec 接口，解决了 USB2.0 的问题，也可以和安卓设备一样用高速传输了。
]]>大疆的机器每次连接都要走这个流程，不得不说真的很麻烦。这个 Wi-Fi 的记忆功能比较鸡肋。
连接之后需要右上角先把视频下载到手机本地，然后点击分享。
这里可以选各种软件，比如 airdrop，微信，邮件。我这里选懒猫微服，点击之后就会跳转到懒猫网盘。
第一次传输我发现速度慢的离谱。询问了售后才发现 ios 会默认在 wifi 网络不好时走流量的。
因为大疆的 pocket3 传输需要连接相机的 Wi-Fi。所以手机是整个一断网额的状态。这流量也不快。
偷偷跑流量是手机和运行商的传统了，那么在蜂窝网络里给他关掉。关掉无线局域网助理。
关了之后，再重复上边的操作，就发现懒猫网盘打不开了，嗯 这就是预期的行为了，不会偷偷的用网了。
于是询问大疆额售后能不能让机器连接家里的网，得到的回答是不行。只能手动切换 Wi-Fi。
换了网之后再传输，这个速度就舒服多了，虽然没跑满千兆，但是也能够看了。
然后把上一步的视频文件夹共享出来，以后把素材都发到这个文件夹里。再共享给其他的懒猫用户，就很方便了。
]]>两个很想吐槽的地方
- 大疆 pocket3 不能直接连家里 Wi-Fi，传文件到网盘必须换网
- Apple 的 lighting 原生不支持 OTG，需要买转接头。
https://appstore.lazycat.cloud/#/shop/detail/xu.deploy.env
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE
Expected sha256 4ceb…
Got 5519987f…
因为 pip 在校验阶段就失败，后面的 Flask 等依赖都没装上，于是程序启动时报 ModuleNotFoundError: No module named ‘flask’。
最后我还是替换掉了腾讯云。以清华源为主，其他源为辅：
1 |
|
网上还有几种办法，后面再遇到的时候可以再尝试：
参考链接：
]]>open 状态的，可以正常写入和搜索。当你暂时不使用某些索引，但又不想删除它们时，可以通过 close 操作来关闭索引，从而释放部分内存资源。使用以下命令可以查看当前集群中所有索引的状态：
1 | GET _cat/indices?v |
创建一个索引并插入数据：
1 | POST abc/_doc |
此时你会看到索引 abc 已创建，并处于 open 状态：
默认每个索引有 1 个主分片、1 个副本分片，且为可读写状态。
如果你暂时不需要某个索引，又不希望删除它，可以将其关闭：
1 | POST abc/_close |
返回结果：
1 | { |
关闭索引后，不仅不能写入，连搜索都无法进行。
1 | GET abc/_search |
返回：
1 | { |
1 | POST abc/_doc |
返回：
1 | { |
1 | POST ab*,test/_close |
返回结果：
1 | { |
确认索引状态：
1 | GET _cat/indices?v |
当需要重新启用这些索引时：
1 | POST */_open |
返回：
1 | { |
有些场景中（如运营平台防止误操作），管理员可能会禁止索引关闭操作。设置如下：
1 | PUT _cluster/settings |
返回结果表示设置已生效：
1 | { |
再次尝试关闭索引时，将返回如下错误信息：
1 | { |
执行：
1 | GET _cluster/settings |
结果会包含：
1 | { |
| 操作 | 是否支持 | 条件 |
|---|---|---|
POST /<index>/_close | ✅ 默认支持 | 除非设置 cluster.indices.close.enable: false |
POST /<index>/_open | ✅ 总是支持 | 无需额外开启 |
POST ab*/_close | ✅ 支持批量关闭 | 同上 |
| 查看关闭限制配置 | GET _cluster/settings?include_defaults=true |
关闭索引适用于资源控制、调试排查等场景，但要注意：关闭索引仍会占用磁盘空间，不会释放存储，仅仅是节省内存和 CPU 资源。
]]>我们看一看开发懒猫应用，需要什么样的知识？
那么，开发懒猫微服的应用需要掌握哪些技能呢？
懒猫微服的 CLI 本质上是一个通过 NPM 全局安装的工具包，因此掌握一些基本的 NPM 使用方法是必要的。
1 | npm install -g @lazycatcloud/lzc-cli |
这个工具是用 JavaScript 编写的，但如果你只是为了使用而非开发，那么并不需要掌握这门语言。当然，你也可以选择使用 pnpm 或 yarn 作为包管理工具，或者通过 NVM 来创建 Node.js 虚拟环境。
如果在 macOS/Linux 上遇到了权限不足的问题，其实不一定要使用 sudo。默认情况下，npm 的全局目录是 /usr/local，普通用户对其没有写权限。比如我们可以看到：
1 | ll /usr/ |
因此我们可以通过设置 npm 的全局安装目录，规避权限问题。在当前用户目录中创建一个文件夹并添加到环境变量中即可：
1 | npm config get prefix |
开发的技能是可选的，如果你只是移植现有的应用的话，那么具备一些 Docker Compose 的知识就足够了，这个我们后面再说。
如果是开发原创 APP 的话，那么无论是 Vue，React，Go，Python 都有用武之地，只要是 Web 的应用能够本地运行或者打包成 Docker 就能上架商店。相信很多开发的小伙伴也会做一些 Devops 的事情，这部分的技能是可以完全迁移过来的。
很多 NAS 是基于 FreeBSD 或者 Linux 改的，懒猫微服是基于 debian12， 虽然在设计之初是针对非专业玩家。但是后来也开放了 SSH，可以做和其他 Linux 一样的事情，给了 root 用户，所以可以底层操作文件，网络，查看分区，监控，以及系统负载。
所以不是只有树莓派或者自己笔电装机才能学 Linux，懒猫微服的系统重启之后会复原（除了 root 目录和网络设置），所以请随便折腾。
虽然有了一套很完善的图形客户端，但是相信很多专业的玩家还是更加喜欢用传统 Linux 的方式来看待这个微服，我管他叫做拆解系统设计。
举个例子：用 htop 查看负载、用 nmtui 配置网络、用 lsblk 查看磁盘分区、用 systemctl 设置服务自启。深度定制的系统，让我们可以完全无视内核，以及 grub 的这些东西。甚至连 sambda，webdav 这些 server 都不用自己安装。
Docker 好像对 NAS 玩家是必须的，无论是群晖，威联通。与传统 NAS 不一样的是，懒猫微服集成了三套 docker，分别是系统组件，playground 和应用商店。
playground 就是我们刻板印象的 Docker， 这里叫做pg-docker，所以需要懂一些 Docker 的知识，比如下载，打包，上传，还有数据卷的贡献。甚至包括 Docker- compose 的使用。
应用商店也是基于 Docker 运行的，
上架软件时有两种方式：
直接打包：这个一般用于原创应用或者移植开源无 docker 版本的应用。调试的时候可以使用懒猫内置的 Docker Registry 的 image 进行测试，颇有 VS code remote 的风格。这个调试模式叫做 devshell。
Docker 镜像迁移：一般用于已有的 docker image 的迁移，由于国内出海宽带不足，访问 Docker 经常失败。所以需要使用懒猫提供的 Docker Registry 来做一个国内版本的镜像。然后再做目录的映射。
这个稍稍有点跑题，前面的都是传统 Devops 需要的东西。这里的 OIDC 叫做 OpenID Connect，是单点登录实现的一种。传统的认证有基于 cookie 的，或者基于 JWT 的。OIDC 是后者，也是单点登录中最优雅的实现。除了 OIDC 之外，你可能听说过 SAML，Oauth，其实也都是 Single Sign-On 的不同实现，而 Oauth 是和 OpenID Connect 源同一脉，Oauth 的各家实现千差万别，而 OpenID Connect 既统一了规范，解决用户态的问题。换句话说 OAuth 2.0 只是用来授权，颁发的是Access Token，而对于访问者是谁还需要开发人员自己存数据库。OIDC 则是引入了ID Token，这通常是通常是 JWT，所以认证直接请求 IDP 解码就好了。大致是这个流程：
下图是 OIDC 的基本流程：
如果你熟悉 Web 开发、Docker 和基本的 Linux 操作，那么你已经可以快速上手懒猫微服的应用开发。无论是移植开源项目，还是开发原创 App，只要能够在本地运行或打包为 Docker 镜像，就可以顺利上架到应用商店。
懒猫微服不仅仅是一个面向普通用户的 NAS 系统，更是一块为开发者打造的自由试验田 —— 它就是一台稳定可靠的 Debian 云主机，你可以在上面尽情发挥创意与技术。
]]>答案是：通过挂载 docker.sock 文件来实现跨容器控制。
所以我们可以在商店的 APP 中操作 playground docker，其实也就是 Docker 面板或者轻量 Docker 面板做的事情。
为什么不操作其他两个 Docker 引擎？
build.yml 中挂载 Playground 路径首先，在打包配置 build.yml 中新增 services 字段，用于将宿主机中的 /data/playground 挂载到容器内部：
1 | manifest: ./lzc-manifest.yml |
打包后会生成一个名为 compose.override.yml 的文件。请注意：即使你手动创建了 compose.override.yml，也可能无法直接生效，必须通过打包流程自动生成。（此结论基于初步测试）
生成后的 compose.override.yml 内容如下：
1 | services: |
manifest.yml 实现 docker.sock 映射为了让上架 App 操作 Docker，需要手动编辑 manifest.yml 文件，添加以下内容：
1 | binds: |
这样，容器内的 Docker CLI 或管理面板就可以通过 DOCKER_HOST 环境变量，控制宿主机的 Docker 引擎。
manifest.yml 示例以下是完整可运行的 manifest.yml 配置：
1 | lzc-sdk-version: 0.1 |
通过挂载 docker.sock 文件和设置 DOCKER_HOST，我们可以让商店上架的 App 控制懒猫微服的 Playground Docker 实例。我用这个功能上架了自己写的 Docker 面板，一起来玩一玩嘛？
另一个槽点是 apple 把启动台去掉了，改成了 apps，用搜索栏统一搜索。
除了检索应用，也能检索邮件和文件什么的，属于是一键搜索了。
那么我们怎么改原来的启动台呢？执行这两个命令然后重启：
1 | sudo mkdir -p /Library/Preferences/FeatureFlags/Domain |
GPT 解释如下：
1 | #### 第 1 行： |
重启之后我们的启动台就回来了：
由于懒猫网盘采用多租户架构，每位用户的数据是隔离的。因此，访问路径通常为：
1 | smb://<ip>/<用户名> |
在开始挂载前，请确保你已在懒猫微服后台开启了“内网访问服务”，否则 SMB 连接会被拒绝。
以前在上机考试时，老师会将题目放在服务器共享目录中，我们用 Win + R 输入 \\IP地址 来下载资料，当时还觉得这操作很高端。
解释：
这是通过 Win + R 快捷键打开“运行”窗口，输入 \\<IP> 快速访问局域网 SMB 共享目录。通常用于临时打开文件夹，不做映射。
在 Linux 或 macOS 上，可以直接用以下地址挂载：
1 | smb://<ip>/Download |
或者通过 mount.cifs：
1 | sudo mount -t cifs //192.168.1.100/your-username /mnt/share -o user=your-username,password=your-password |
在 Windows 中，需要通过图形界面手动挂载为本地磁盘，操作如下：
解释：
在这里你可以：
Z:, Y:, X: 等）；\\192.168.1.100\your-username）；系统将提示输入用户名和密码：
成功后，可以在“此电脑”中看到挂载好的 SMB 网络盘：
你可以像操作本地硬盘一样打开、拖拽、复制文件。
我测试了一下，将文件从 SMB 网盘拖入 PVE 虚拟机，传输速度稳定在 500MB/s，表现不错。
打包的时候偷了个懒，直接打包的没有用容器，然后其中一位用户就遇到这个问题：
要了下日志，结果是发现访问清华源有问题，被清华源直接返回了 403，这个问题还比较稀奇，毕竟在我的印象里清华源一直都很稳。
1 | -------------logs:------------- |
GPT 查询了下，可能就是 IP 给限制了。
打开清华的 Pypi 的页面，看到这位的 IP 确实被清华拦截了。
为了防止这个情况，有两个办法：
1 | pip config set global.extra-index-url "https://mirrors.aliyun.com/pypi/simple/ https://repo.huaweicloud.com/repository/pypi/simple/ https://mirrors.cloud.tencent.com/pypi/simple/" |
然后可以使用 pip config list 查看,能看到我这个是走了腾讯云的：
1 | pip install pandas |
对于 SDK 而言，可以通过在 HTTP 请求中携带用户名和密码，或使用 SignV4 携带 IAM 身份信息进行认证。
常见的解决方案包括：
OpenID Connect（OIDC）是在 OAuth 2.0 协议之上构建的一个身份层，用于实现单点登录（SSO）和身份验证。以下是 OIDC 的详细验证流程：
2024 年 6 月 19 日 Amazon OpenSearch 在全球区上线了 JWT 认证授权功能，中国区的北京和宁夏区域的此功能在 2024 年 6 月 23 日上线控制台增加了 JWT authentication and authorization 功能，启用此功能需要开启精细访问控制，并导入验证 JWT 有效性的证书。
配置 JWT 认证授权的步骤包括在 IDP 中创建 API，并使用 API 获取 JWT。以下是使用 Auth0 生成 JWT 的示例代码：
1 | import requests |
我们在 Auth0 中新建一个 API，然后会帮我们生成一个 Application。后续我们会使用这个 Application 的 Client ID 和 Secret ID 以及 Domain 的信息来登录。
也就是说这三个信息确定了一个身份池，然后符合规则的用户可以通过这个身份池来换取 JWT。可以在 Applications-Applications 中看到。
配置好之后，可以通过 Auth0 的 API 来拿到登录后的 JWT，以下是一个官方给的教程可以用来测试功能，当然也可以集成到 APP 中。
auth0 也提供了示例代码供我们测试：
官方提供代码样例可读性不是很高，让我们用用 requests 来改写一下，这个代码会把生成的 JWT 存在一个 Json 文件里面，这样我们就能容易的复制出来。
1 | import requests |
我们可以看到控制台多出了一个 JWT authentication and authorization 新功能，使用这个功能需要先开启精细访问控制，我们需要在这里需要导入验证 JWT 有效性的证书。
服务端需要填写验证 JWT 的 PEM 证书，那么我们要从 Auth0 的 API 中拿到这个信息。使用如下代码从.well-known/jwks.json 中解析出来需要的证书，然后填写到 OpenSearch 中。
1 | import requests |
配置好后，可以在 OpenSearch 的安全配置中看到 “View JWT details” 信息，验证 JWT 的有效性。通过标准的 JWT 流程使用 Postman 验证时，将 JWT 输入到 Bearer token 中，即可进行验证。
然后我们按照标准的 JWT 流程进行验证，这里使用 Postman，验证方式使用 Bear token，我们把通过应用程序模拟的 JWT 输入进去。
我们也可以使用编程方式来进行访问，其实就是上加上一个’Authorization’: ‘Bearer
1 | import requests |
几个月前，我参与了一些内部功能的审核工作。当时认为，既然系统支持 JWT，那么这应该也意味着支持 OIDC IDP，并且能够解决中国区 Cognito 无法集成的问题。然而，通过测试发现，JWT 仅能在编程方式中使用，控制台仍然需要使用原来的认证方式。也就是说，预想的从控制台跳转到 OIDC IDP 的方式仍然无法实现。期待未来能够实现从控制台无缝跳转到 OIDC IDP 的目标，为用户提供更便捷和安全的使用体验。
【3】https://docs.aws.amazon.com/zh_cn/opensearch-service/latest/developerguide/JSON-Web-tokens.html
]]>点对点连接：VPC Peering 是一个点对点的连接，每次只能连接两个 VPC。如果需要连接多个 VPC，需要为每对 VPC 单独设置 Peering 连接，也就是我们常说的不能进行路由的传递，需要打通的 VPC 很多的时候会非常的麻烦。
手动路由配置：每个 VPC Peering 连接都需要手动配置路由表，这在大规模环境下非常繁琐。
集中式管理：TGW 作为一个中央枢纽，允许多个 VPC 和本地网络通过单个网关相互连接，简化了网络架构和管理。
自动路由传播：TGW 支持自动路由传播，简化了路由配置，减少了人为错误的风险。
跨账户和跨区域支持：TGW 支持跨多个亚马逊云科技账户和跨区域的连接，提供更大的灵活性和扩展性。
总结下来说，TGW 就是是一个中转网关，使用时候需要在需要打通的 VPC 内创建一个挂载点，TGW 会管理一张路由表来决定流量的转发到对应的挂载点上。本质上是 EC2 的请求路由到 TGW，然后在查询 TGW 的路由表来再来决定下一跳，所以需要同时修改 VPC 内子网的路由表和 TGW 的路由表。
TGW 的网络拓扑图如下：
登录到亚马逊云科技管理控制台，导航到”VPC”服务。
在左侧菜单中选择”Transit Gateways”，点击”Create Transit Gateway”。
填写 TGW 名称和描述，配置 DNS 支持等选项。
根据要求创建 TGW，如果不需要和本地网络打通，这里填写名称和描述就好。
建议开启以下三个选项：
DNS support：开启打通 VPC 的 DNS 支持，这个 DNS support 无法解析对端的私有 R53 记录，还需要使用 Resolver 才行 [^1]
Default route table association：自动创建一个路由表并且关联这个 TGW
Default route table propagation：自动路由表自动传播，这样每次更新的时候就不用手动管理路由。
在 TGW 创建完成后，导航到”Transit Gateway Attachments”。
点击”Create Transit Gateway Attachment”，选择目标 VPC 并配置相关选项。
创建挂载点需要选择关联的 TGW 以及挂载点的 Type，除了 VPC 之外还有 peering，DX 类型的可供选择。
同样这里也要开启对 DNS 的支持，另外关于 Appliance Mode support，如果这个功能开启的话，流量只能在相同的可用区进行转发，这个功能开启需要慎重考虑。
手动新建 TGW 的路由表并且关联到一个 TGW，如果前面开启了 Default route table association 和 Default route table propagation 不再需要此步骤。
需要在 Routes 部分手动添加路由规则
为每个 VPC 配置路由表，添加到 TGW 的路由。确保启用路由传播，使 VPC 可以通过 TGW 相互通信。
和 peering 一一样，需要把对应的流量指到对端，这里 10.1.0.0/16 的流量到 TGW。
如果需要跨账户打通网络，那么需要用到 TGW 的 share 功能，其实就是使用 RAM 进行资源共享。
如果需要跨账户共享 TGW，使用 AWS Resource Access Manager (RAM)。
在 RAM 控制台中创建资源共享并邀请其他 AWS 账户。
对方也是需要在 RAM 里进行确认，并且接收方不能二次 share 此 TGW。
拓展阅读：
https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway.html
通过这些文档，可以全面了解 TGW 在跨区域连接中的显著优势，确保在大规模和复杂网络环境中的高效、安全和可扩展性。
]]>AWS IAM Identity Center（身份中心，原 AWS SSO）作为 AWS 官方提供的集中式身份认证与访问管理服务，可以作为企业的 主身份提供商（IdP）。通过 SAML 2.0 协议，它能够将认证结果传递给其他云服务商（如阿里云），让用户在 AWS 完成一次身份验证后，直接进入阿里云控制台，而无需再次登录。这就是所谓的 跨云单点登录（Single Sign-On, SSO）。
本文将结合详细步骤与截图，完整演示如何配置 AWS IAM Identity Center 与阿里云 RAM 的 SAML 对接。
在正式配置 SAML 对接之前，我们需要先在 AWS IAM Identity Center 中创建用户。
在用户创建完成后，需要在 AWS IAM Identity Center 中配置一个 应用（Application），它代表与阿里云之间的对接关系。
操作步骤：
📌 说明：
AlibabaCloud-SAML。在配置过程中，你可能注意到 AWS 提供了多种协议选项，其中最常见的就是 OAuth 2.0 与 SAML 2.0。
📌 区别解析：
| 对比项 | SAML | OAuth |
|---|---|---|
| 核心用途 | 单点登录（SSO），跨云、跨域身份认证 | 应用授权，第三方应用获取资源 |
| 数据格式 | XML | JSON |
| 常见场景 | 企业员工访问云平台、内部系统 | 微信/Google 登录第三方应用 |
| 安全特性 | 强调身份认证 + 授权 | 强调令牌授权，不负责身份本身 |
| 适合对象 | 企业 IT 管理，多云环境 | C 端互联网应用 |
在创建好应用后，AWS 会为我们生成一个 元数据 XML 文件，其中包含：
📌 操作方法：
⚠️ 注意事项：
接下来，切换到 阿里云 RAM 控制台，新建一个 身份提供商（Identity Provider）。
📌 步骤：
在阿里云中，也提供了一个默认的 SAML 元数据地址：
👉 https://signin.aliyun.com/saml-role/sp-metadata.xml
但在本场景下，我们需要导入 AWS 提供的 XML，因为 AWS 是 IdP，阿里云是 SP。
在 AWS IAM Identity Center 应用配置页面，需要把实际用户分配到该应用。
📌 操作细节：
⚠️ 注意事项：
DevOps-Team、Finance-Team。这个应用程序的属性映射如下：
1 | [https://www.aliyun.com/SAML-Role/Attributes/RoleSessionName](https://www.aliyun.com/SAML-Role/Attributes/RoleSessionName) awssso(可以自定义） |
阿里云侧还需要配置一个 角色（Role），与身份提供商进行绑定。
角色配置完成后， 信任策略如下，例如：
在 AWS 上可以看到我们新建的应用程序。
📌 说明：
role/iamssorole 表示阿里云角色。saml-provider/iamsso 表示 AWS IAM Identity Center 提供的身份。👉 可配置的属性：
RoleSessionName：会话名称，通常可设置为 awssso 或自定义值。Role：指定的阿里云角色 ARN。https://www.aliyun.com/SAML-Role/Attributes/RoleSessionName
https://www.aliyun.com/SAML-Role/Attributes/Role
在配置过程中，阿里云官方也提供了一些参考文档，例如：
https://help.aliyun.com/zh/ram/user-guide/implement-role-based-sso-from-ad-fs
虽然文档以 AD FS 为例，但本质上对接 AWS IAM Identity Center 的原理是一样的。
配置完成后，可以在 AWS IAM Identity Center 的 SSO 页面进行验证。
在 Dashboard 中，点击分配好的 “Alibaba Cloud” 应用：
此时用户会自动跳转到阿里云控制台，无需再次输入用户名和密码：
通过本文的配置流程，我们实现了 AWS IAM Identity Center（IdP） → 阿里云 RAM（SP） 的单点登录：
我们的产品名称是“拍立懂”，团队名称是 “凌晨三点的夜”。主要是拍照识别商品成分、品牌资质，分析价格合理性，为老年人提供购买决策建议；通过实时语音聊天交互，亲人语音陪伴老年人购物，满足空巢老人的情感空缺。
我们的项目团队汇聚了文化创意创业者、资深互联网产品经理、互联网技术博主与 AI 前端工程师等多元背景，形成从商业策略到产品落地的完整闭环。团队成员对创新技术和用户价值怀有共同的热情，彼此协作、优势互补，致力于在商业模式和技术实现上持续突破，为项目注入持久动力。
说人话版本:
“拍立懂”首页：先定位、再拍照、还可语音，一站式搞定逛超市！
进入小程序，系统会自动识别你所在的门店，保证每一次推荐都“本地有货”。
- 对准商品“拍一拍”，AI 秒识品牌与规格，为你生成成分/营养解析；
- 打开语音助手，直接问“这款油健康吗？”，即时语音作答；
- 想逛逛热卖？下拉切换「日用食品 / 零食饮料 / 时令食材」，AI 列出今日在售优质清单。
拍照 + 语音 + 实时库存，让你逛超市不再纠结，用 AI 把复杂信息说得清清楚楚。
架构图如下：
这个是最初的设计。
“拍一下成分表，让 AI 帮你读懂配料、评估健康影响，真正做到买得安心、喝得放心。”
“坚果零食好不好？拍立懂 3 秒告诉你！”
拍照上传后，AI 自动识别到「烤坚果夹片 145 g × 24 片」，并细致解析：
- 坚果种类、外层配料、甜味剂 / 添加剂 全部列出；
- 逐项点评对心血管、体重管理、过敏风险的影响；
- 支持一键切换到「营养价值」查看热量、蛋白质等详细数据，或点「选购建议」获取更健康替代品。
拍立懂 —— 把复杂配料表翻译成人话，让零食的健康度一眼可见！
“无需打字，长按语音键即可提问。拍立懂即刻为你解惑，让购物沟通更流畅。”
]]>⏰ 凌晨三点的夜 还在码字、调参，但有热情就不困。
拍立懂，让爸妈“拍一拍就懂”，也让我们更懂爸妈。
这张图是创始人在用户群里发的实拍图：
据群友们聊天说，这台机器已经经过了多个版本迭代，最后定型为现在这个样子。以后不要再用鞋盒了。
通过 neofetch 可以看到，这台机器预装的是 Debian 12，实际系统也做了不少魔改优化。核心配置如下：
<DEL> 。 没有锁 BIOS，也支持刷成其他的系统。运行 dmidecode 可见内存状态如下：
1 | sudo dmidecode -t memory | grep -e "Size" -e "Form Factor" -e "Locator" |
网络配置方面也比较主流：
1 | (base) lzcbox-029c588e ~ # dmesg | grep -i ethernet |
于 WIFI6 来说协商速率一般是 2402Mbps，所以就算达到协商速率的一般的话，也就是差不多千兆，加上很多家用路由也仅仅是千兆，我为了 POE 供电所以牺牲了部分内网带宽，所以没有跑满。如果你有 2.5G 的机器和交换机，那么一定可以跑的很舒服，基本就到机械硬盘的上限了。
跑了几次 geekbench6，能够看到单核心的性能有 1700+，由于测速的同时还在运行很多系统应用，所以实际的数值比这个还要大一些。
后面用了 EndeavourOS KDE 的随身碟，能够看到单核心分数还能再提升。这个 CPU 跑 docker，K8S 甚至虚拟机都没啥问题了。
机器背部接口一览，我这边插了一张采集卡，非常实用：
接口方面也非常丰富：
整机搭载一枚 17mm 涡轮静音风扇，结合滚珠轴承与自研调速算法，实际体验确实安静，确实没有 3.5 寸硬盘那种炒豆子的声音了。
可以看到 Deepin 的 团队出来做产品的能力还是挺强的，从主板到 OS 的深度定制，技术功底可见一斑。
下面是群友的发的效果图，实物质感确实很棒，欢迎找我下单体验！
uptime，果然 3 分钟之前重启了。懒猫的 BIOS 有上电自启的功能，所以能够看到确实是停电了。
使用 uptime -s 显示系统最后一次启动的具体时间
然后又看了看群晖，群晖接到了 UPS 上，几乎没受到啥影响。
昨天刚把懒猫从 UPS 上拿下来，因为发现 UPS 有无线干扰。结果第二天就遇到断电，果然是怕啥来啥。
先看看开机时间：
1 | journalctl --list-boots # 列出所有启动记录 |
重点观察：
LAST ENTRY：上次关机时间FIRST ENTRY：本次启动时间
可以看到从 08:31 到 08:41，系统中断了 10 分钟，符合意外断电并自动重启的特征。
然后看看关机日志，基本都是昨天的手动关机的日志，今天意外断电的日志丢失，也在情理之中。
1 | journalctl -b -1 | grep -i "shutdown\|power\|crash\|kern.*panic" # 检查上次会话 |
如果是正常关机，会有 systemd-shutdown 或服务停止记录；
如果是异常断电，则日志会直接中断，没有“收尾”。
到这基本上可以确定是 08 点 31 断电的了，再拉下系统日志：能看到好好的 UPNP 的日志突然中断。然后 10 分钟后转为开机日志。基本上可以确定是意外断电。
1 | journalctl -S "2025-06-17 08:30:00" -U "2025-06-17 08:42:00" |
赶紧查下 SMART 信息，还好没啥事。
1 | smartctl -a /dev/sda |
因为在 Apple Silicon（如 M1/M2 芯片）设备上，默认运行的是 ARM 架构镜像（linux/arm64）。但有些镜像或依赖只支持 X86（linux/amd64）架构。
本文将介绍如何在 ARM 设备上拉取并运行 X86 镜像，以及如何保存和加载镜像。
使用 --platform=amd64 参数即可拉取 X86 架构镜像：
1 | docker pull --platform=amd64 nginx:latest |
docker pull：从远程仓库拉取镜像--platform=amd64：显式指定拉取 x86_64 架构的镜像nginx:latest：镜像名与标签适用于在 M 系列 Mac 上使用 X86 镜像进行兼容性测试或运行仅支持 x86 的应用。
拉取完成后，可通过以下命令确认镜像架构：
1 | docker image inspect nginx:latest --format '{{.Os}}/{{.Architecture}}' |
示例输出（成功拉取 X86 架构）：
1 | linux/amd64 |
执行以下命令尝试运行时：
1 | docker run --rm -it --platform=amd64 nginx:latest |
可能会出现如下错误：
1 | docker: Error response from daemon: image with reference nginx:latest was found but its platform (linux/amd64) does not match the specified platform (darwin/amd64) |
Docker 镜像是 基于 Linux 内核 的容器运行时，不支持 darwin/amd64 平台。你应显式指定目标平台为：
1 | --platform=linux/amd64 |
1 | docker run --rm -it --platform=linux/amd64 nginx:latest |
此时 Docker Desktop 会自动调用 qemu 进行跨架构模拟（无需额外配置），即在 ARM Mac 上模拟运行 X86 容器。
Docker 提供 save 和 load 命令，支持将镜像打包导出为文件，便于备份或跨设备迁移。
.tar 文件1 | docker save -o nginx-amd64.tar nginx:latest |
-o nginx-amd64.tar：导出的文件名nginx:latest：指定要导出的镜像标签也可以一次保存多个镜像：
1 | docker save -o images.tar nginx:latest redis:alpine |
.tar 镜像文件使用 SCP 或者 FTP 传到懒猫微服上，使用以下命令导入：
1 | docker load -i nginx-amd64.tar |
导入成功后镜像将出现在 docker images 列表中。
如果你从懒猫微服上保存了镜像（如 linux/amd64 的 nginx），在 ARM Mac 上可通过以下方式运行：
1 | docker run --rm -it --platform=linux/amd64 nginx:latest |
压缩后更便于传输：
1 | docker save nginx:latest | gzip > nginx.tar.gz |
解压并导入：
1 | gunzip -c nginx.tar.gz | docker load |
| 操作 | 命令 |
|---|---|
| 拉取 X86 镜像 | docker pull --platform=amd64 nginx:latest |
| 运行 X86 镜像 | docker run --rm -it --platform=linux/amd64 nginx:latest |
| 保存镜像 | docker save -o nginx.tar nginx:latest |
| 加载镜像 | docker load -i nginx.tar |
如果是在 懒猫微服 运行 ARM 镜像呢？
1 | docker pull --platform=linux/arm64 nginx:latest |
或简写为：
1 | docker pull --platform=arm64 nginx:latest |
这会拉取适用于 linux/arm64 的 nginx 镜像（即 ARM 设备如 Raspberry Pi 或 Apple Silicon 可运行的版本）。
1 | docker run --rm -it --platform=linux/arm64 nginx:latest |
Docker Desktop 会通过内置的 QEMU 模拟 ARM 架构运行该容器。
⚠️ 前提是你的 Docker 环境启用了 QEMU 多平台支持（默认大多数 Docker Desktop 安装都已经启用）。
方案一：确认 QEMU 是否已配置（X86 主机想运行 ARM 镜像）
如果你在 Intel / X86 主机上运行 –platform=linux/arm64，需要先启用跨架构支持：
1 | docker run --rm --privileged multiarch/qemu-user-static --reset -p yes |
进入容器执行：
1 | uname -m |
输出应为：
1 | aarch64 |
说明该容器运行在 ARM 架构上。
如果遇到：
exec /docker-entrypoint.sh: exec format error
意味着：你尝试在一个 与镜像架构不匹配的主机或模拟环境中运行该镜像，导致容器入口脚本无法被执行。
| 目标架构 | --platform 参数 | 常见用途 |
|---|---|---|
| X86 (Intel/AMD) | linux/amd64 | 默认平台，大多数镜像的标准版本 |
| ARM (如 M1/M2/Raspberry Pi) | linux/arm64 | 在 Apple Silicon 上或嵌入式设备运行 |
| 在 X86 上模拟 ARM | --platform=linux/arm64 | 跨架构测试、兼容性验证 |
套件中心搜索 SynoCli，然后安装 SynoCli Monitor Tools ，里面有常见的监控工具。
然后在群晖上启动服务端：
1 | name@qun:~$ iperf3 -s |
在 Mac 上测速，iperf3 -c 和
这两个命令的差别关键在于 数据传输方向，也就是谁是“发”谁是“收”。
iperf3 -c <server_ip>🧪 示例：
1 | iperf3 -c 192.168.5.171 |
表示测试从你这台机器上传数据到服务器的带宽。
iperf3 -c <server_ip> -R🧪 示例：
1 | iperf3 -c 192.168.5.171 -R |
表示测试从服务器下载数据到你的机器的带宽。
| 命令 | 数据方向 | 谁发送 | 谁接收 | 测的是什么带宽 |
|---|---|---|---|---|
iperf3 -c | 客户端 → 服务器 | 客户端 | 服务器 | 上传带宽 |
iperf3 -c -R | 服务器 → 客户端 | 服务器 | 客户端 | 下载带宽 |
g5.2xlargeDeep Learning OSS Nvidia Driver AMI GPU PyTorch 2.7 (Ubuntu 22.04)打开 AWS 官网，点击右上角登录。
选择 使用 Root 账户登录：
输入 root 邮箱和密码，若首次登录需要绑定 MFA（建议使用 Authenticator App）：
进入 AWS 控制台后，选择左侧的 EC2，点击右上角的 “启动实例”。
选择操作系统镜像（AMI）：
搜索并选择：
1 | Deep Learning OSS Nvidia Driver AMI GPU PyTorch 2.7 (Ubuntu 22.04) |
自带了 NVIDIA 驱动、nvidia-container-toolkit、Docker 等，无需额外安装。
选择实例类型：g5.2xlarge（带 A10G GPU）
创建密钥对：系统会生成 .pem 格式的密钥，下载后：
1 | chmod 400 your-key.pem |
网络设置：
安全组设置：
使用 SSH 登录 EC2 实例：
1 | ssh -i your-key.pem ubuntu@<EC2公有IP> |
查看基本系统信息（需先安装 neofetch）：
1 | sudo apt update && sudo apt install neofetch -y |
查看 GPU 驱动是否正常：
1 | nvidia-smi |
查看是否已安装 nvidia-docker 插件：
1 | docker info | grep -i nvidia |
接下来按照 NVIDIA 官方文档进行 Isaac Sim 的容器部署即可：
👉 文档链接：
https://docs.isaacsim.omniverse.nvidia.com/4.5.0/installation/install_container.html
RtPso async compilation 阶段较久（10 分钟左右），这是因为光线追踪 shader 正在编译。只要缓存持久化，之后启动会非常快（1 分钟内）。通过 AWS 的 G5 系列实例（搭载 A10G GPU），我们可以方便地在云端部署 Isaac Sim。选用 NVIDIA 官方预装驱动的 AMI，可以省去繁琐的 CUDA 和容器配置。搭配持久化缓存和合理的端口管理，即可稳定高效运行 Isaac Sim 的云端仿真。
]]>因为苏堤，我们聊到东坡，美食以及宦海沉浮。聊到最爱的粤菜和川菜更是共同的爱好，去成都旅游的时候找他要了攻略，并且约定下次去她的城市旅游给我当导游。
https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.shell.files
加了微信一直零零碎碎的聊着。一个周末的早上，她找我帮忙转换视频格式。由于微信的限制无法发送大文件，于是我建议她通过懒猫网盘传给我。
于是开始做思想工作，把数据上传到我的家里的懒猫微服上。这里还是感谢信任和支持，没有认为我这个是一些诈骗盗取的网站。（毕竟曾经在学校讨论代理问题，被文科生当成黑客）
然后开账户，她的 windows 好像没有可以扫码的地方，所以我帮助她注册好，然后发给她。和她自己注册不一样的是，她的设备我登录时候我这边会弹出“安全码”，然后再发给她，这样她就就可以自己处理登录的问题了。我给她开了懒猫相册，清单，网盘和一些好玩的 APP，除了处理这个事情之外，也希望后面也能慢慢用起来其他的功能。
我是一个非常不喜欢 MFA 的人，但是这个二次验证还是能够接受。常规的 MFA 是每次登录都要手动输入二次验证码，而这个相同的设备只需要一次。虽然从系统设计的角度上看二者没有太大的区别，但是还是感觉这个设计，用来节约我们浪费在二次验证上的时间。我们不是牛马，我们是人，我要相信自己的验证。
然后我告诉他把文件上传到网盘上，然后共享整个文件夹给我。在我的不完全测试下只有文件夹才能共享，然后操作完文件之后再做同样的操作共享给她。毕竟对比被共享人而言，这个目录是只读的，所以我们用共享给对方来完成这个操作。
当然中间有个小插曲，就是上传需要等好久。她的是文科生所以对网络一知半解。一开始还以为她家的网速慢，还稍微吐槽了下。
上传完成之后，我于是让她测试下家里的网速。毕竟以前找我修电脑的姑娘，不是电脑配置过时就是，几乎完全的电脑盲。然后测试下来发现她家的网速还算可以，主要是国内的运营商限制比较多。国内是唯一按照 BGP 收费的，加上还要打击 PCDN，所以每家的上传少的可怜，30MBPS 是刚好能玩的水准，转算成实际的速度嘛，还是等等吧。
实际上，她给我的文件竟然有 15 个 G 多。这种大文件如果不是自建 NAS 或者商业方案根本没有传输的办法。QQ 和微信限制大小，就连邮箱也要限速 5 个 G。最早以前，我们用的办法就是，分段压缩成多个压缩包，然后一个个传给对面，对面再用相同的办法解开。十分麻烦并且耗时。而使用传统的 NAS 还要面临不定时封端口的噩梦，装机师傅和客服都解释不清楚，没有地方去问。虽然家里有公网 IP，但是不想每天被这种琐碎的问题困扰，当初购买懒猫微服也是最喜欢他们这个穿透的卖点。内网传统的是永恒的问题，然后是动态域名解析，做好还要加上健康检查，之前休假的时候把家里的机器透传到公网上，然后三五天就被封端口，但是回去看的时候内网怎么都是好的，但公网 telnet 依然有问题，除非重启路由器更换 IP。
现在我不用为了网络穿透的问题烦恼了，不用担心二次验证以及黑客攻击的问题。用拓竹的例子来说吧，只有用懒猫是在玩 NAS，其他的传统硬件都是在折腾。折腾固然好，兴趣价更高。若为自由故，二者皆可抛。
懒猫带给我的，是丰富的硬件资源和社群沟通，以及售后的专业和及时。花钱买省心，剩下抄作业。大抵如此了。
✅ 目标：只用两台服务器（或同一台）就跑通 “向量检索 + 本地大模型” 原型
✅ 特点：完全离线、依赖极少、部署脚本即文档
✅ 适合：快速 PoC、内网合规场景、想深挖 RAG 工作机理的开发者
生成式 AI 聊天固然强大，但当问题依赖本地私有知识时，单靠 LLM 参数内的“世界记忆”往往答非所问。RAG（Retrieval-Augmented Generation） 的思路是：
多数教程直接用云端 Embedding+OpenAI GPT-4o，但一些团队因隐私、成本或离线环境无法这样做。
本文选用：
1 | 用户问题 ──▶ 嵌入模型 (Ollama) ──▶ EasySearch 向量检索 ──▶ Top-k 片段 |
nomic-embed-text（768 维，多语言通用）knn_dense_float_vectordeepseek-r1:7b（轻量，好部署；可换 llama3 / qwen）1 | import os, json, requests, warnings |
1 | # Python 依赖 |
1 | # ────────────── 配置区 ────────────── |
这段代码只是给脚本提前设定一些“连接参数”与“模型选择”，方便后面统一引用。逐行解释如下：
1 | ES_URL = "https://<es_host>:9200" |
ES_URL：EasySearch / OpenSearch 集群的完整地址（含协议与端口）。
<es_host> 是占位符，实际部署时要替换成你的 IP 或域名。http://10.0.0.8:9200。1 | ES_AUTH = ("elastic", "password") # 无认证设为 None |
ES_AUTH：连接集群的账号密码元组。
requests 的 auth= 参数，会自动加 Basic Auth 头。None。1 | INDEX = "rag_demo" |
INDEX：向量索引（或文档索引）的名称。
"knowledge_base"。1 | OLLAMA_HOST = "http://<ollama_host>:11434" |
OLLAMA_HOST：本地 Ollama 服务的 HTTP 起始地址。
<ollama_host> 也是占位符；若脚本与 Ollama 在同一台机器，可写 http://localhost:11434。11434 是 Ollama 默认 REST 端口。1 | EMBED_MODEL = "nomic-embed-text" |
EMBED_MODEL：用于生成文本向量（embeddings）的模型名。
client.embeddings(model=EMBED_MODEL, …)。ollama pull <模型名>，确保本地已下载。1 | CHAT_MODEL = "deepseek-r1:7b" |
CHAT_MODEL：负责最终回答的聊天 / 生成式模型。
client.chat(model=CHAT_MODEL, …) 进行对话。llama3:8b-chat、qwen:7b-chat 等，先 ollama pull 再改这里。client 是连接 Ollama 模型服务的客户端，用来发请求。
session 是访问 Elasticsearch 用的请求会话，能提高网络效率。
用指定的嵌入模型（比如 nomic-embed-text）把文本转成向量，用于相似度搜索。
用指定的聊天模型（比如 deepseek-r1:7b）回答问题，返回回复文本。
1 | # ────────────── 初始化 ────────────── |
在构建基于向量的 RAG（Retrieval-Augmented Generation）系统时，我们首先需要在向量数据库中创建一个支持向量检索的索引。本文使用 EasySearch 作为底层存储，向其中注册一个支持近似向量搜索的索引结构。
create_index 函数的作用是通过 RESTful API 创建一个名为 rag_demo 的索引，并定义字段结构如下：
content：文本内容字段，类型为 text，可用于全文搜索或作为上下文返回。
vec：向量字段，类型为 knn_dense_float_vector，支持高维向量的快速相似度搜索。
配置中使用了 LSH（局部敏感哈希）模型与 cosine 相似度度量，同时设定了近似参数 L 与 k，分别控制候选样本数量和返回结果数。
通过设定 “index.knn”: True，该索引支持使用 k-NN 查询来高效地检索与查询向量最相似的文档。在实际使用中，嵌入模型如 nomic-embed-text 可将输入文本转换为高维向量，存入此索引中，与用户查询语义对齐，实现高效的语义检索能力。
1 | # ---------- ① 创建索引：Elastiknn 映射 ---------- |
以下是对这段 bulk_upload 函数的简明解释，可用于博客正文或技术文档：
在 RAG 系统中，为了支持高效的语义检索，我们需要将原始文本与其对应的向量一起写入向量索引中。bulk_upload 函数正是完成这一任务的核心组件，它使用 Elasticsearch 的 _bulk 接口实现批量写入，显著提高写入效率。
每条记录包含两个部分：
index 元数据，指定目标索引（rag_demo）及文档 _id。
实际文档内容，包括：
content：原始文本内容；vec：对应的文本向量，必须使用 {"values": [...]} 的对象结构。向量通过 embed(t) 获得，调用本地部署的 Ollama 模型（如 nomic-embed-text）生成。
所有数据最终编码为 JSON，通过 Content-Type: application/x-ndjson 提交到 /_bulk API 接口，实现一次性批量写入。
1 | # ---------- ② 批量写入：向量必须包 {"values": …} ---------- |
这段 search 函数的作用是在 RAG 系统中执行基于向量的语义检索，以下是适合用于博客中的简明解释：
RAG 系统的核心是从向量索引中找到与用户问题最相近的语义片段。search 函数即完成了这个过程，它调用 EasySearch 的向量检索接口，返回最相似的文本内容。
文本向量化：通过 embed(question) 把用户输入的问题转换成向量 qvec。
构造检索请求：
使用 knn_nearest_neighbors 查询
field: 向量字段名（本例中是 "vec"）；vec: 查询向量，必须写成 { "values": [...] } 的对象结构；model: 向量近似检索模型（如 "lsh"）；similarity: 相似度度量方式（如 "cosine"）；k: 返回的结果数；candidates: 候选池大小，用于粗排优化检索效果。发送请求并解析响应：
请求通过 Elasticsearch _search 接口提交，若返回不成功，则输出报错信息；成功后提取 _source["content"] 字段，返回给上层用于回答生成。
用户提问：“张三是谁”，系统会将该问题向量化，然后在已有文本向量中进行相似度匹配，从而返回如“张三是法律专家……”的片段，作为构建回答的上下文。
这段逻辑是 RAG 模型“Retriever”阶段的核心，让大模型在“有知识”的基础上作答，提升准确性和实用性。
1 | def search(question: str, top_k: int = TOP_K): |
1 | # ────────────── CLI 主逻辑 ────────────── |
1 | Q: 张三擅长什么 |
结果如下：
完整代码：
1 | import os, json, requests, warnings |
]]>EasySearch × Ollama 让我们在本地就能体验到“RAG 的爽点”：检索带来实时、可信的上下文，大模型负责自然语言表达，二者合体即是一个可交付的“企业私有知识助手”。如果你也想在内网快速验证 PoC，这份脚本拷过去改两个地址即可开跑。祝玩得开心！
自从被种草了 Amazon Q，我陆陆续续写了不少小软件，其中这个 Docker 客户端是一个典型的例子，比较符合自己平时使用的习惯，也分享给一些朋友和 NAS 爱好者来用。
故事还要用上次折腾黑群晖说起，本意想把 NAS 和打印机共享二合一的，所以把闲着的软路由做了改装。顺便使用 Docker 跑一些服务，有老本行的 ES 集群，也有自己写的一些工具类型的服务。
随着时间增长，部署的服务多了，时间长了就会忘记服务的端口，甚至还要登录群晖 Web 端进行查看，群晖的 Container Manager 很好用，就是登录的密码策略比较复杂，每次登录都比较麻烦，所以后来使用了一个 HomePage 来保存这些服务。但是每次调试 Docker 都非常麻烦。与 Portainer 相比，我需要的只是一个简洁的面板来查看容器的 URI、状态，并进行启停操作，因此我决定自己开发一个。
这个是群晖的 Container Manager，后面还有很多容器。记住这么多端口然后随时维护绝对不是一个容易的事。
我开发容器面板叫做 Containly， 是一个 Container 的管理工具。最早的时候用我是用 GPT 写的。但是随着项目越来越大，GPT 每次都会丢一些东西，而且还没办法操作本地目录，后来才转向了 Amazon Q，这个版本还是用 Q CLI 来做的。
于是写好之后我把这个 APP 上架了懒猫微服的商店，这个是一款国产化的 NAS，可玩性非常高，对开发者也十分友好。上线当日就有很多开发者安装使用了。
Containly 的核心功能是通过目录映射的 Docker 引擎读取所有容器信息，包括容器的启动、退出、停止及其他状态。例如，当容器处于“Create”状态时，它会被标记为“Other”状态，便于管理。
默认情况下，每个容器卡片会显示容器的网桥信息、端口映射和 URL。默认使用 HTTP 协议，鼠标悬停时，会在右侧显示操作按钮。通过点击这些按钮，操作会被保留，再次点击会隐藏，这样子就整个比较美观。
按钮功能包括：
此外，Containly 还提供了一个输入框，用户可以输入需要监控的 NAS 域名，面板会自动根据域名和端口拼接成 URI，并存储在 localStorage 中。更进一步，Containly 还支持暗黑模式，提升了用户体验。
另外如果多节点部署服务的话，还可以把从节点放入黑名单，这样子就只显示主节点的信息，面板就比较清爽。如果需要从节点的信息再从黑名单移除。
利用面板的 SSH 功能， 能够直接从面板进去访问容器的 SHELL，不用执行再 docker exec 的命令。
看日志也很方便，也无需再使用 docker logs，这样调试容器的时候就很方便了。
我已经打包好了 Docker 镜像并配置了 GitHub Actions，便于自动化部署。你可以通过以下方式部署 Containly：
1 | docker run -d \ |
1 | version: "3.8" |
这个是使用 Q 修改的部分代码截图：
后来机缘巧合之下用了 Q pro，看来也不能优化再多。
除了使用 Q CLI，我们还可以通过安装 VSCode 和 JetBrains 插件来使用 Q，安装插件后，免费版本可以使用 Builder ID 登录，Pro 版本则支持使用 IAM Identity Center 登录。
在 VSCode 中，你可以通过 Q 聊天面板与 Q 进行交互，并且支持中文聊天。
与 GPT 相比，Q 的优势在于它可以直接操作本地文件，用户可以直接在文件夹中生成工程文件，极大提升了开发效率。
云厂商的 ECR。但是对于个人玩家或者爱好者来说这一套实在是太重太难以维护了，可能也就是这个原因，懒猫微服也提供了镜像仓库的和本地仓库的功能。
先说镜像仓库，就是从懒猫微服的服务器上先拉 Docker image，然后再推到自己的 registry。这一步骤通常由出海链路比较好的机器来完成。
懒猫提供了便捷的镜像同步命令：
1 | lzc-cli appstore copy-image cloudsmithy/lazycat-nav |
执行之后就可以看到镜像仓库，registry.lazycat.cloud 这个地址。
重要说明：
这个地址只能在微服环境中使用，如果在其他地方使用会出现认证错误：
1 | docker pull registry.lazycat.cloud/u04123229/cloudsmithy/lazycat-nav:854b14e73ab0726e |
其实就一个加了认证的 registry，只是微服有凭证可以直接进。
懒猫微服内置了一个简化版的 registry，完整使用流程如下：
1 | # 构建x86架构镜像 |
实际操作演示：
在 M2 芯片设备上的构建过程：
在 Orbstack 上拉取验证（先删除本地镜像再拉取）：
通过 API 查看镜像列表：
这个简单版本的 docker registry v2，后面用来做跑 CI 的镜像仓库应该是够了。
如果遇到这个问题，千万别信 AI 是 buildX 坏了，就是中文路径的问题。（AI 查一小时。Google 一分钟）
1 | docker-container:multiarchERROR: failed to dial gRPC: rpc error: code = Internal desc = rpc error: code= Internal desc =header key"x-docker-expose-session-sharedkey" contains value with non-printable ASCII characters |
对于这种场景来说，前端项目开发完成后，我们将构建好的静态页面部署到服务器上。借助 Docker 和 Nginx，可以实现一套轻量、快速、可移植的部署方式，特别适合懒猫微服这种容器化的环境，也很适合日常调试测试使用。
下面将手把手教你如何打包一个 Vue 或 React 项目，并通过 Docker + Nginx 构建一个可复用的前端部署容器镜像，然后就可以把这个部署到懒猫微服删，当然也适用于各种 Linux + Docker 环境。
纸砚双拼是 Vue 的项目，所以直接执行这个命令打包
1 | npm i |
打包完成后，项目根目录下会生成一个 dist/ 文件夹，里面包含：
index.html基本所有前端工程化的流程都是部署这个 dist/静态目录。
在开始容器化之前，我们先来整理一下项目结构。
1 | my-static-site/ |
主要就是把 dist/ 目录映射到 Nginx 的根目录。
.dockerignore（防止把 node_modules 等大文件复制进镜像）项目根目录建议加个 .dockerignore 文件，防止无用文件进入镜像、浪费空间：
1 | node_modules |
这里的 dist 虽然是构建产物，但因为我们用的是双阶段构建，会在容器里重新生成，不需要提前放入。
我们采用双阶段构建方案，能够最大限度减小最终镜像体积，只包含运行时必须的内容。
1 | # 构建阶段 |
- 使用
node:alpine和nginx:alpine轻量镜像，构建出来的镜像体积非常小- 分阶段构建，确保生产镜像中没有多余文件
Nginx 配置文件如下：
1 | server { |
执行以下命令构建镜像并启动：
1 | docker build -t my-frontend . |
打开浏览器访问 http://localhost:8080，确认页面正常显示。如果用的是懒猫微服，可通过它的 web 浏览器或 ssh 转发方式访问容器。
如果本地调试可以使用
1 | version: "3" |
打包多了之后 Docker 会积累不少旧镜像、缓存和挂载卷，下面这些命令能够清理磁盘空间：
使用 pg-docker 或者 lzc-docker 来替代
1 | docker compose build --no-cache |
不使用任何缓存，适合依赖变动或调试构建问题时使用。
1 | docker system df -v |
查看镜像、容器、网络和卷的占用情况，排查“空间去哪了”。
1 | docker system prune -af --volumes |
]]>删除所有未使用的镜像、容器、网络和卷，释放最大磁盘空间。
注意：慎用，可能会清掉你没保存的 volume 数据。
heiyu.space 这个域名就得安装客户端，突然发现懒猫微服的客户端都是图形化界面。对于服务器环境，特别是没有图形界面的服务器，我们需要纯命令行解决方案。随着公网 IPv4 地址即将枯竭，许多云厂商的学生机也不再提供公网 IP，这迫使开发者寻找异地组网方案。虽然 Tailscale 是一个可选方案，但作为懒猫微服用户，我更希望利用懒猫自带的组网功能实现这一需求。
在 VIP 群咨询后，获得了服务端组网工具：
https://gitee.com/lazycatcloud/hclient-cli
和花生壳的 CLI 类似，但是比花生壳省心多了。（这里不再过多吐槽花生壳系列了）
1 | chmod +x ./hclient-cli-$arch # 首次启动需要添加可执行权限 |
初始运行会提示：
当前为非 tun 模式,仅支持通过 http 代理访问微服或其他设备资源
然后就会提示当前为非 tun 模式,仅支持通过 http 代理访问微服或其他设备资源，也就是说现在是单项的组网，这肯定不是我的要求，然后 GPT O3 给了我一个答案。
1 | sudo ./hclient-cli-$arch -tun true |
再启动之后，就没有那个 TUN 模式的提示了。如下
然后需要使用命令添加，bname 是机器的名字，uid 和 password 是用户名和密码，这样就保证了全球唯一性质，执行完第一步的时候已有的客户端会弹出验证码，执行完第二步就会消失。
1 | # 添加微服 |
在懒猫微服设备监控中可以看到加入的设备。
一开始去访问我写的面食比例计算机，发现了重定向了，才想到懒猫默认给所有的应用加了一个认证。
1 | <a |
商店里的 elasticsearch 放行了所有路由，这样我们在终端和 SDK 就不再需要走那个 web 的验证了，不然只能在请求头里面硬塞 cookie，但是如果是多层认证就非常的难搞。从图片中可以看到，我们从云服务器可以成功访问到家里的懒猫微服了。这个代表从云服务回到家里时没有问题的。
其实更多的时候我们的异地组网是为了能够在没有公网 IP 的情况下访问节点，查一下监控设备中的域名，然后 ssh 访问进去，发现基本没什么问题。所以就能够双向访问了，这样我们组网的目的就达到了。
通过懒猫微服的 CLI 工具，我们成功实现了：
PXE，全称 Preboot eXecution Environment，是一种允许电脑在没有本地操作系统、光盘或 U 盘的情况下，通过网络从服务器下载引导程序并完成系统安装的机制。
PXE 装机简化流程如下：
1 | 1. 开机 → BIOS/UEFI 设置为从网卡启动（PXE Boot） |
以下是我在懒猫微服环境中使用 iVentoy 的全过程：
进入懒猫的应用数据目录：应用数据 - Iventoy - ISO
将你准备好的 Windows / Linux ISO 文件上传到此路径。
确保机器在内网下有一个 有效的 IPv4 地址，然后启动 iVentoy。
进入待装机设备的 BIOS，确保启用 PXE Boot / 网络启动功能。
启动设备，确保插入网线（无线网卡 PXE 启动通常不被支持），从网卡启动。
如果网络配置无误，设备会自动弹出引导菜单，可以看到之前上传的 ISO 镜像。
选择一个系统镜像，回车进入即可，相当于将 ISO 当成 LiveCD 使用。
以 Pop!_OS 为例，系统已经顺利启动，无需任何 U 盘！
这个办法还是适合炫技，把电脑接上网线，然后不用 U 盘，凭空装好系统，不过还是没有 U 盘那么丝滑，有时候不能打满千兆带宽。不过假如手头 U 盘不够用，或者要在多个系统反复装机测试就很方便了。
]]>
1 | wget https://github.com/ventoy/Ventoy/releases/download/v1.1.05/ventoy-1.1.05-linux.tar.gz |
这个默认是启动在 localhost，如果需要外网访问改成 0.0.0.0，运行 ./VentoyWeb.sh 后，你会看到如下提示：
1 | ./VentoyWeb.sh |
翻了翻脚本，是在这里改。
因为我本地通过 dig 解析懒猫微服的域名是 IPV6，所以没办法直接访问,于是我通过 SSH 创建一个本地端口转发（Local Port Forwarding）隧道：
1 | ssh -N -L 24680:127.0.0.1:24680 root@lzc |
ssh: 启动 SSH 客户端。-N: 不执行远程命令，仅用于端口转发（即登录后不打开 shell）。-L 24680:127.0.0.1:24680: 本地端口转发规则，格式为 本地端口:远程地址:远程端口。解释如下：24680: 本地监听的端口（你访问 localhost:24680 时会触发转发）。127.0.0.1: 这是 SSH 远程主机上的地址，指代远程主机自己。24680: 最终目标端口。root@lzc: 使用 root 用户连接名为 lzc 的主机（可以是域名或 /etc/hosts 里配置的别名）。当本地访问 localhost:24680，会通过 SSH 加密通道转发到远程主机 lzc 上的 127.0.0.1:24680，就像直接在远程主机上访问一样。
这个就是 Ventoy 的页面了，由于默认懒猫没有 GUI，所以没办法使用类似 windows 那种客户端，还好 Venoty 提供了一个 web 端可以用来玩。
点击右侧的绿色，
接着 Ventoy 会再确认一次是否格式化设备，务必确认盘符无误，这一步会清空整盘数据，后期可以无损升级。
写盘成功的提示，后期只需要把 ISO 直接拖拽进来。
正巧群友推荐了一个神器 —— chsrc。这个工具支持一键切换系统、Python、conda 等多个主流组件的源，简洁高效，非常适合懒猫微服这样的轻量环境使用。
chsrc 项目在 Gitee 上提供了预编译的可执行文件，适用于不同架构的 Linux 设备。我当前使用的是 x86_64 架构，因此只需运行以下命令：
1 | curl -L https://gitee.com/RubyMetric/chsrc/releases/download/pre/chsrc-x64-linux -o chsrc |
下载后，为了方便使用，我们通常会把它加入环境变量。但懒猫微服的一个特殊机制是：除了 /root 目录，其他目录在每次重启后都会被重置。这意味着如果你将 chsrc 放在 /home 或 /usr/local/bin 之类的目录，它在下次重启后可能就不见了。
所以我将 chsrc 的二进制文件移动到了 /root/app 下（可以新建这个目录），并在 ~/.bashrc 中手动追加了环境变量：
1 | export PATH=/root/app:$PATH |
这样每次打开 shell 时，系统就会自动把 chsrc 所在路径加入 $PATH，确保我们可以直接使用 chsrc 命令。
懒猫微服是基于 Debian 的发行版，因此可以直接运行：
1 | chsrc set debian |
运行后，工具会先检测系统当前源格式（支持新版 deb822），然后测速多个国内镜像源（如清华、中科大、阿里等），自动选择最快的源进行替换，整个过程完全自动化，再也不用去网上搜帖子找各种源了。
除了操作系统本身的源之外，也能更换 Python，node 这样的源。
我制作了一个 Miniconda 的一键安装脚本，用来替代系统自带的 Python3.11，用 conda 虚拟环境管理起来很方便。
1 |
|
这个脚本的好处是全程自动化，不需要你动手点选目录，也不必一步步设置环境变量，适合懒猫开发者在新设备或系统还原后快速恢复工作环境。
安装好 Miniconda 之后，就可以利用 chsrc 来更换 pip 源了：
1 | chsrc set python |
此命令会将 pip 的默认源改为清华源或豆瓣源等国内镜像，提高模块下载速度，彻底告别“卡在安装 xx 模块”的窘境。
最后一步，把 conda 的源也换成国内的。直接执行：
1 | chsrc set conda |
然后需要手动更新 .condarc 配置文件。
这次我体验了 chsrc 在懒猫微服上的完整使用链路，感受可以总结为三句话：
如果你也在用懒猫微服、或者在其他 Debian 系的轻量服务器上摸索开发环境，强烈推荐你试试这个工具和脚本组合。毕竟，“懒得配置”不应该成为“卡在配置”的理由。
优点：
缺点：
优点：
缺点：
帮助大家更好地准备和选择考试内容。我总结了亚马逊云科技现在的认证：
首先，您需要访问 https://aws.amazon.com/certification注册一个账户。我建议使用私人邮箱注册，而非公司邮箱，以确保账户的长期可用性。
点击使用 Pearson Vue 进行安排：
在这里可以选择线上、线下和私人访问码，一般选择前两种，第三种通常是与机构合作的链接。
线下考试需要带好身份证，国内还需要带辅助证件，如社保卡或驾照。
线上考试需要保证良好的网络环境和独立的空间，同时准备好身份证。
接下来是选择考场，这里可以同时选择三个考场，然后下一步查看考场的时间：
可以看到最近的日期是 15 号，那么我们可以尝试预约 15 号。
选好时间之后，下一步准备付款。如果有优惠码，可以在下一步输入。这里可以看到考试时间汇总。
付款完成后，可以下载 ics 文件并添加到日历中，这样的话 Apple 日历就会提前提醒我：
对于非英语母语的考生，可以申请 30 分钟的加时。虽然官网也发布了中文考生可以加时 30 分钟的消息，但尚未说明具体的加时条件。
线上检录界面，需要做一些准备工作，上传证件，清理桌面之类的工作：
这个是线上和考官的聊天界面：
如果需要申诉，会邮件告知新的抵扣码（原来的考试码作废）：
希望这些信息能帮助大家在备考过程中做出最优选择，顺利通过亚马逊云科技认证考试。
]]>
从邮箱里给的链接注册，登录。然后绑定 MFA，这个 MFA 其实就是一个二次验证，如果账户被盗，对方没有 MFA 也是无法登录的。
我用了 2Fauth 来绑定的，当然你也可以使用 google authenticator 之类的软件，绑定六位动态码。当然比较常见的 MFA 就是短信验证码，当然还有打电话的。这边刚刚登录，这边电话马上过来。
注册成功会有这个提示。后面需要使用这个绑定的 MFA 进行登录。
登录之后会跳转到这个门户页面，点击 Q 的图标之后会跳转到 Amazon Q 的官方文档。
完成了登录，我们来做本地的配置：
在 VS code 商店中搜索 Amazon Q 并且安装：
Amazon Q 有免费版和 Pro 版。免费版使用 build ID 进行登录，无需 AWS 账户。而今天体验的是 Q pro 版本，还好主办方给配置好了 AWS 的账户，
安装之后右下角就有一个提示登录的弹窗，点击 Sign in，URL 输入邮箱里给的 URL。其实就是 IAM identity center 的登录链接。
然后是跳转浏览器：
以及提示打开浏览器的弹窗：
浏览器打开之后有获取权限的提示：
点击允许之后就大功告成了：
同时 VScode 里的 Q 也会变成这样，最后变成聊天窗口
如图是聊天模式：
如果你使用 Ubuntu server：
下载命令行：
1 | wget https://desktop-release.q.us-east-1.amazonaws.com/latest/amazon-q.deb |
安装
1 | sudo apt-get install -f |
打开，然后同样的通过浏览器打开：
1 | q |
如果你用的是苹果系统，就更简单了。从这个链接下载，直接安装就可以了。
https://desktop-release.q.us-east-1.amazonaws.com/latest/Amazon%20Q.dmg
然后在终端中输入 q 或者 Q chat 就可以了。
不然我访问 Dockerhub 是这样的，经常会超时，只能用不是很全的镜像站。
群晖等设备提供的图形化网络面板，懒猫微服这类轻量系统没有 GUI，只能使用命令行工具。NetworkManager 提供了一个非常好用的文本界面工具：nmtui。
nmtuinmtui 是 NetworkManager 的 TUI（Text-based User Interface）组件，界面类似简化版 GUI，操作简单，功能却很强大。通过它，我们可以方便地完成以下配置：
1 | nmtui |
打开 nmtui 后，进入“Edit a connection”，编辑你连接的网卡（如 enp2s0），手动设置 IP 地址、网关和 DNS。如下图所示，我将所有网络解析都指向了旁路由（比如是 OpenWrt 或其他带翻墙能力的设备）：
确保设置完成后，运行以下命令重新应用配置：
1 | nmcli device reapply enp2s0 |
如果配置无误，网络将立即切换到静态 IP 并走旁路由的网关。
这样子终端就能下载 Docker image 了，其实到这一步已经完成了。
接下来，可以通过懒猫微服中安装的浏览器测试网络是否生效。
继续打开 YouTube 首页，也能顺利访问并加载视频页面：
你没看错，这是 浏览器里的浏览器，实现了一个“浏览器套娃”的效果。😂
最终，我播放了银临的《牵丝戏》，人美歌也好听～
因此，这一篇教程就来介绍如何在懒猫微服上安装图形桌面环境，并通过 XRDP 实现远程桌面连接。我们选择的是轻量级的 XFCE4 桌面环境，它资源占用小，运行稳定，界面风格有点像老版本 Windows，非常适合资源有限的 VPS 或微型容器环境。当然，你也可以选择 KDE Plasma、GNOME 等更现代的桌面环境，但安装包体积和资源占用会更高。
经过多次测试，我总结了一份实用的一键安装脚本，适用于基于 Debian 的系统（如 Ubuntu 或懒猫微服）：
1 |
|
你只需要将这段脚本保存为 install-xrdp-xfce.sh 文件，赋予执行权限并运行即可：
1 | chmod +x install-xrdp-xfce.sh |
需要注意的是, 重启之后这个配置仍然会消失.所以还需要使用 systemd –user 拉起来这个脚本.
如果你连接后出现黑屏问题，通常是 .xsession 配置不正确或者权限不足，上述脚本中已经处理好了这个问题。
如果你希望在物理机或有显卡输出的虚拟机中直接打开图形界面（不是远程连接），可以额外添加如下配置：
1 | echo "exec startxfce4" > ~/.xinitrc |
这样你在本地终端执行 startx 就能启动 XFCE 桌面。
通过上述脚本，我们可以非常快速地为懒猫微服安装一个可用的图形桌面环境，并通过 XRDP 实现远程访问。这在需要图形界面支持的场景下尤其方便，例如：
如果你希望安装 KDE、GNOME 等更复杂的桌面，可以将 apt install 中的包名替换为 kde-standard、gnome 等，并注意资源占用问题。
/root/），这就给我们留下了一条生路。以往每次重启后，我都要手动重新安装 htop、sudo、httpie 等工具，重复操作实在麻烦。之前在 VIP 群里沟通过能否允许使用 systemctl 自启脚本，现在终于支持了 systemctl --user 的开机启动功能，第一时间来体验一下！
我们把需要安装的软件统一写进一个脚本，只安装未安装的部分，避免重复浪费时间。同时也支持远程安装一些工具，例如 superfile。
1 |
|
你可以把这个脚本保存为 /root/init.sh（懒猫微服会保留这个路径），并赋予执行权限：
1 | chmod +x /root/init.sh |
由于懒猫微服现在支持 systemctl --user，我们就可以通过用户级 systemd 服务在登录后自动执行该脚本。
在 ~/.config/systemd/user/ 目录下创建服务文件：
1 | mkdir -p ~/.config/systemd/user |
内容如下：
1 | [Unit] |
注意事项：
ExecStart 使用 /root/init.sh 是因为懒猫微服重启不会清空 root 目录；default.target 是用户级别的“登录后启动”目标。配置好之后，使用以下命令启动并设置自动运行：
1 | systemctl --user daemon-reload # 重新加载用户服务配置 |
1 | systemctl --user start bootstrap-packages.service |
输出如下：
1 | ○ bootstrap-packages.service - Bootstrap Required Packages |
图示效果如下（安装过程中终端自动拉起）：
| 步骤 | 命令 |
|---|---|
| 设置 systemd 服务 | vim ~/.config/systemd/user/bootstrap-packages.service |
| 测试运行 | systemctl --user start bootstrap-packages.service |
| 设置登录自启 | systemctl --user enable bootstrap-packages.service |
| 查看运行状态 | systemctl --user status bootstrap-packages.service |
搭配懒猫微服的 root 持久策略和 systemd 用户服务功能，我们终于实现了：重启自动恢复开发环境，不用每次手动装包了！
下面演示如何把懒猫微服配置成一台云端开发机，并分别用 VS Code 与 PyCharm 进行远程开发。
虽然懒猫微服的商店已经上架了 code-sever 可以开箱即用，除此之外我们也来探索下其他的方案。
修改 ~/.ssh/config（若无自行创建）：
1 | Host lzc |
终端测试：
1 | ssh lzc # 应直接登录而不再提示密码 |
需要 Remote Development 三件套插件（SSH / WSL / Containers）。
~/.ssh/config，显示刚才的 lzc 主机。
我们再来看 Pycharm，默认提供了远程开发的功能。记得最早 Jetbrains 的是这么实现的，把本地代码推送到远端的/tmp 文件夹然后调用远端编译器执行。现在用了 Gateway 基本可以达到实时的效果了。
/root/...）。
apple 的 M 芯片用来开发，而懒微服就作为上线环境之前的测试环境，当需要 X86 环境的时候，随时切换过去。
一直想写一本容器小书，真好懒猫基本都做了容器化，所以把这部分分享出来。不同的是，懒猫微服中使用 pg-docker 来替代 docker 命令，使用 dockge 来执行 docker-compose。以下讲解以标准 docker 为主，这样子既学会了 docker 知识，也能够在懒猫微服上启动 Docker 服务。
随着项目日益复杂，小李的服务已经不再是一个容器就能承载的了。
前端、后端、数据库、缓存、日志系统……像一个交响乐团，需要统一调度、和谐配合。
老周递给他一个新的工具：“Docker Compose——它是你的指挥棒。”
老周解释：
“Docker Compose 是 Docker 的多容器编排工具，用一份
docker-compose.yml文件，就能同时启动、停止、构建多个服务。”
Compose 帮你解决：
docker-compose.yml小李的项目结构如下：
1 | myapp/ |
docker-compose.yml 示例：1 | version: "3.9" |
🔧 每个
service就是一个容器定义，Compose 会为它们创建默认网络，自动 DNS 互通。
小李在项目目录下运行：
1 | docker-compose up -d |
后台启动所有服务！
其他常用命令：
| 操作 | 命令 |
|---|---|
| 构建镜像 | docker-compose build |
| 后台启动 | docker-compose up -d |
| 前台启动 + 日志输出 | docker-compose up |
| 停止服务 | docker-compose down |
| 查看容器日志 | docker-compose logs [服务名] |
| 重启某个服务 | docker-compose restart 服务名 |
| 进入某个容器 | docker-compose exec 服务名 bash |
老周介绍：
“Compose 默认创建一个网络，所有服务能通过服务名互相访问。”
在上面的例子中：
backend 容器可以用 db:3306 连接 MySQLfrontend 可通过 backend:5000 访问后端 API小李不再需要手动
docker network create和--network参数，Compose 一切自动打通。
Compose 中的 volume 显式声明（如 dbdata:）会自动创建、管理。
支持：
1 | volumes: |
.env 管理配置变量Compose 支持使用 .env 文件集中管理变量：
.env 文件：
1 | DB_PASSWORD=123456 |
Compose 文件中使用方式：
1 | environment: |
🚀 配合 CI/CD 时
.env可由流水线动态生成，便于多环境切换（dev/stage/prod）。
1 | restart: unless-stopped |
确保服务宕机时能自动重启。
1 | build: |
可指定构建路径、Dockerfile 文件、构建参数等。
1 | healthcheck: |
| 特性 | Compose | Kubernetes |
|---|---|---|
| 启动容器 | 简单 | 标准化 |
| 配置语言 | YAML | YAML |
| 网络 | 自动共享 | 需显式配置 |
| 存储 | Volume | PVC + SC |
| 服务发现 | 服务名互通 | DNS/ClusterIP |
| 用途 | 本地开发 / CI | 集群部署 / 云原生 |
| 高可用 / 伸缩 | ❌ | ✅ 内建 |
| 社区生态 | 中小项目广泛使用 | 大型平台标准方案 |
小李理解了：Compose 是“轻量乐队指挥”，K8s 是“交响级 AI 指挥系统”。
小李将 Compose 整合进 GitLab CI 流程：
.gitlab-ci.yml 示例：
1 | services: |
CI 构建完镜像后，直接用 Compose 部署，既省事又稳定。
| 目标 | 技巧 |
|---|---|
| 服务隔离 | 每个项目单独一个 Compose 文件 |
| 共享网络 | 不用写 network，服务名即 DNS |
| 跨环境配置 | 使用 .env 动态切换变量 |
| 状态排查 | docker-compose logs / ps / exec |
| 多环境文件 | 使用 docker-compose.override.yml |
| CI/CD 联动 | 编排命令嵌入流水线任务中 |
当小李敲下 docker-compose up 的回车键，前端、后端、数据库同时启动，日志齐鸣，服务稳定运行。
“这就是我梦想的微服务协奏曲啊。”
老周拍了拍他肩膀：
“你已经能用 Compose 驾驭服务之海，下一步，是把它们部署上云、扩展弹性、自动滚动升级。”
小李点头，望向远方的集群编排系统——Kubernetes，眼中闪着新的渴望。
好！那我们就在第五章《多容器交响曲》中，继续深入补充这四大实战技能：
小李希望同一套服务，在开发、测试、生产环境下分别使用不同的配置，比如：
老周教他使用 Compose 的多文件配置机制：
docker-compose.override.ymlDocker Compose 默认会自动加载 docker-compose.override.yml 并与主文件合并。
1 | docker-compose.yml |
1 | services: |
1 | services: |
运行：
1 | MODE=development docker-compose up |
适合 CI/CD 或部署多个 stage。
docker-compose.dev.ymldocker-compose.prod.yml运行：
1 | docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d |
多个 -f 会按顺序合并，后面覆盖前面。
📦 建议主文件写“公共配置”，子文件按环境细化。
小李发现，即使写了 depends_on，后端有时候也连不上数据库。
老周摇头说：
“
depends_on只是控制启动顺序，不是等服务就绪。数据库可能还没监听端口就已被标记为 ‘up’。”
比如 Flask 等数据库：
1 |
|
或者使用工具包如 wait-for-it.sh：
1 | COPY wait-for-it.sh /wait-for-it.sh |
🩺 推荐结合容器健康检查，判断服务是否真正 ready。
小李的 CI 工具用的是 Compose v1，项目准备升级。
老周提醒：
“Docker Compose v2 使用的是
docker compose（空格），而非docker-compose（短横线）。”
| 项目 | v1 (docker-compose) | v2 (docker compose) |
|---|---|---|
| 命令格式 | docker-compose up | docker compose up |
| 安装方式 | 独立二进制 | 集成于 Docker CLI |
| 文件格式 | v2, v3 | 推荐统一 v3.9 |
docker-compose 二进制docker compose CLIlinks）.env 是否兼容（v2 更严格）当小李进入 Kubernetes 世界，他问老周：
“Compose 文件和 K8s 的 YAML 有啥对应关系？”
老周说：“很好理解，Compose 是开发者的 K8s 简化版本。”
| Compose | Kubernetes |
|---|---|
services: | Deployment + Pod |
volumes: | PersistentVolumeClaim |
ports: | Service（NodePort / ClusterIP） |
depends_on: | initContainers 或 readinessProbe |
.env | ConfigMap / Secret |
docker-compose.yml | Helm Chart (values.yaml + templates) |
1 | services: |
values.yaml：1 | image: |
deployment.yaml（模板）：1 | containers: |
✅ 小李意识到，Helm 是“模板化 + 分层管理”的 Compose 超集，是云原生部署的标准组件管理器。
小李已经用 Docker Compose 实现了：
他明白了：
]]>“Compose 就像舞台排练，Kubernetes 才是真正的大型音乐厅。但有了排练，登台才不会慌。”
一直想写一本容器小书，真好懒猫基本都做了容器化，所以把这部分分享出来。不同的是，懒猫微服中使用 pg-docker 来替代 docker 命令，使用 dockge 来执行 docker-compose。以下讲解以标准 docker 为主，这样子既学会了 docker 知识，也能够在懒猫微服上启动 Docker 服务。
有一天，小李运行了一个容器，里面的 Flask 项目能正常写入用户信息到 SQLite 数据库。可当容器一停止，再启动——所有数据消失了！
老周说：“你的数据，被潮水带走了。”
“Docker 容器默认的文件系统是临时的，只要容器删除，数据也就没了。想让数据真正存活，就要登上‘数据之岛’。”
Docker 提供了三种数据持久化方案：
| 方案 | 用法 | 场景 |
|---|---|---|
| Volume | Docker 管理的专属数据区 | 最推荐、安全、可多容器共享 |
| Bind Mount | 映射宿主机目录 | 更灵活，适合本地调试 |
| tmpfs | 临时存储在内存 | 适合敏感数据，重启即丢弃 |
本章重点讲解：Volume（数据卷） 与 Bind Mount（绑定挂载）
小李重新部署了 MySQL 容器，他决定为数据提供一个“保命空间”。
1 | docker volume create mysql-data |
然后运行 MySQL 时挂载：
1 | docker run -d --name my-mysql \ |
-v 卷名:容器内目录：将卷挂载到容器内数据库文件存储位置。
容器即使删除，数据卷依然保留！
1 | docker volume ls |
1 | docker volume inspect mysql-data |
输出中可以看到 Mountpoint，即数据在宿主机上的物理位置。
小李写了个简单的服务：
1 | VOLUME /app/data |
每次 docker run 时，Docker 会自动生成匿名卷挂载到 /app/data。
但这类匿名卷难以追踪、管理，老周建议：
“生产环境请用具名卷，并在运行时用
-v显式指定。”
开发中，小李想把宿主机的项目代码直接挂进容器，不必每次重建镜像。
1 | docker run -d --name dev-nginx \ |
本地
/Users/xiaoli/site的代码实时反映在容器内网站目录，修改立刻生效！
老周给小李展示了另一个高级玩法：
“多个容器可以挂载同一个卷，共享数据，就像一块公共磁盘。”
小李准备两个容器：
1 | # 写入容器 |
这两个容器在不联网的情况下，通过挂载卷实现了数据同步，让小李直呼神奇。
老周说：
“你现在的数据安全了，但还不够。万一服务器挂了怎么办？你得学会备份。”
.tar：1 | docker run --rm \ |
⛴️ 第一个挂载是数据卷，第二个挂载是宿主机当前目录，输出备份包。
1 | docker run --rm \ |
只需备份 .tar.gz 文件即可，适合迁移数据、升级、容灾。
随着实验多了，小李电脑堆满了无主卷。
查看：
1 | docker volume ls |
清理：
1 | docker volume rm 卷名 |
清除所有未被挂载的孤立卷（慎用）：
1 | docker volume prune |
清理命令要慎重，别误删生产卷！
| 类型 | 命令 | 特点 |
|---|---|---|
| 匿名卷 | -v /path | 难追踪，系统自动命名 |
| 具名卷 | -v myvol:/path | 推荐用法，可管理 |
| Bind 挂载 | -v /host:/container | 与宿主机文件交互，适合本地调试 |
| tmpfs | --tmpfs /path | 内存存储，重启即消失 |
| 权限控制 | -v myvol:/path:ro | 只读挂载 |
| SELinux/AppArmor | :z、:Z（高级安全挂载） | 安全增强场景 |
| 类型 | 内容 |
|---|---|
| 数据库 | 必须挂载 Volume 保持数据持久 |
| 日志 | 推荐落盘到宿主机或集中采集 |
| 配置文件 | 可用 Bind Mount 从本地同步配置 |
| 静态资源 | 静态目录挂载 + CDN |
| 临时缓存 | tmpfs 或容器内路径，无需持久化 |
小李站在一个小岛码头，身后是一个个挂载卷，他的应用和数据终于脱离容器生命周期的束缚。
老周说：
“真正的服务，要能容器随时销毁，数据却永存。”
小李点头，轻轻拍了拍他那卷 MySQL 的备份包，知道自己已经拥有了构建“数据之岛”的能力。
继续拓展高级内容，围绕：
以小李的旅程为主线，继续带你掌握更强大的容器化数据策略。
在一次项目发布中，小李加入了公司的 DevOps 流水线。他发现 GitLab CI 跑测试时，每次都重新构建环境，速度太慢，还会出现缓存丢失的问题。
老周告诉他：
“在 CI/CD 环境中，合理使用数据卷可以极大加快构建速度、保留缓存和数据状态。”
小李把 pip install 改成挂载缓存目录：
.gitlab-ci.yml：
1 | cache: |
🔁 依赖安装过程可被缓存，构建速度提升 50%！
小李部署端到端自动化测试容器：
1 | docker run --rm \ |
测试结果可从宿主机挂载目录或卷中提取，用于后续报告生成或持久存档。
CI/CD 有多阶段：构建 → 测试 → 部署
小李通过挂载共享卷，将编译好的前端包从构建容器传给部署容器：
1 | docker run --name builder -v build-volume:/output frontend-builder |
进入云原生世界，小李不再直接使用 docker run，而是通过 Kubernetes 来编排容器。
在 K8s 中，数据卷概念变得更专业：
小李写了以下 YAML：
1 | apiVersion: v1 |
💡 PVC 是 “我要一个 5Gi 的盘”，PV 是“管理员给你一个”，Pod 中挂上它即可持久保存数据。
| 类型 | 生命周期 | 是否持久 | 典型用途 |
|---|---|---|---|
| emptyDir | Pod 生命周期 | ❌ | 临时缓存、构建产物传递 |
| hostPath | 节点目录挂载 | ⚠️ 有风险 | 本地开发测试 |
| PVC（推荐） | 与集群存储绑定 | ✅ | 数据库存储、日志、持久缓存 |
在云环境（如 EKS、GKE）中，PVC 可以自动创建对应的 PV（EBS、Ceph、NFS 等），只要指定 StorageClass 即可：
1 | storageClassName: gp2 |
这种方式可以实现跨节点迁移不丢数据、按需付费扩容、快照备份等高级功能。
| 场景 | 技术 | 推荐做法 |
|---|---|---|
| 本地开发 | Bind Mount | 映射目录，实时更新 |
| 本地持久化 | Volume | 隔离性好，便于管理 |
| CI/CD 中间数据 | 卷 / 缓存目录 | 挂载 .cache、build 等路径 |
| K8s 中数据存储 | PVC + StorageClass | 可扩展、可备份、可跨节点持久化 |
在 DevOps 流水线中，小李用数据卷构建了无缝衔接的构建流程；
在 Kubernetes 集群中，他用 PVC 实现了跨集群节点的 MySQL 数据持久化部署；
他站在云端存储的星图前，知道自己已经掌握了从 Docker 到 DevOps 再到 Kubernetes 的数据生命周期。
老周拍拍他：
]]>“你已经造好了船，也撑起了帆。下一步，是用 Compose 编排你的舰队。”
故事篇分享我和懒猫微服的方方面面，这里没有高深的技术，也没有过多的讲解。我始终坚信着技术是服务于生活，因为它能够给我们带来小确幸。更多的时候，我们追求技术，有时候为了兴趣，有时候为了心目中那小小的执念。慢慢在这个过程中会成为别人眼中的哆啦 A 梦。懒猫微服是一个百宝箱，我们能拿出千变万化的道具。事情会过去，但是感动和记忆会留下，我们可以随时追忆。
和前端同学约好晚上一起过一遍 API，主要是确认 Swagger 上的接口和字段设置。我事先把后端代码、API 和 Swagger 文档都部署在服务器上，让他先通过浏览器简单预览一遍，然后再开始写前端代码，这样能提前避免前后端格式对不上的问题。
准备开始之前，结果他突然说：‘你的 Swagger 打不开了。我登陆到管理控制台看了下，果然和之前部署 Dify 一样的问题，telnet 端口和 Ping 都正常，但是 SSH 和 Web 应用全都访问不了了。从基本监控俩看，CPU 和磁盘也没什么问题。大概率又是 OOM 了。
DDL 赶在眼前，得赶紧让他连到我的服务器或者开发机才好。第一个想到的是端口转发，把服务映射到公网上去，一方面调试的时候属于明文传输，在互联网上很容易被监听，篡改报文。另一方面，家里的公网 IP 经常出问题，总有一阵子会封禁所有的端口，所以最后采取了异地组网的方式。
我和他说，我在我的 NAS 上给你开一个账户，然后你试试来访问我的 Macbook 上的服务。你去下载一个懒猫微服，下载地址是https://lazycat.cloud/download，然后扫描我给你的二维码，这样就可以访问我的NAS了。（回看这段感觉有点像电信诈骗哈哈，感谢前端同学的信任）
他下载 APP、注册账号，我分配权限后，确认他能正常访问微服主页，就开启了端口转发。把我的 Macbook 的地址和 Web 的端口映射出去，只允许已登录的微服客户端访问。这样就免去了被其他的人中间攻击的烦恼，尤记得第一次把服务公开到整个互联网的时候，日志里出现的 IP 真是天南地北，北欧的，中东的，非洲的……
现在用懒猫微服做异地组网，整个流程只需几分钟，再也不用担心这些琐碎的问题了。
他问了我几个问题。
Q1：网址好像打不开。
A1：你打开懒猫微服试试，或者放在后台。需要靠这个软件来做 DNS 解析。
Q2：你的懒猫是什么，软件嘛？还是硬件？
A2：是一个硬件产品，我拍给你，他带了异地组网的功能。
Q3: 还能穿透其他服务嘛？
A3: 除了线下的设备，微服商店里的服务都能穿透，比如使用 planka 来管理进度，有点 Jira 那个味道了。
民间几种不同的说法：
一些传统公司或者是自己有 IDC 的机房会喜欢第一种说法，而云厂商会采取第二种说法。
这并不是否定公有云的价值，但在使用过程中，除了价格高之外，还有一个现实问题：售后支持常常跟不上。国内这些厂商追求短期效应，心思都放在大客户上，用各种加班来满足大客户的需求，当然也包括一些 24K 纯白的需求。而对于处于调研初期的大公司，小微企业，或者说技术爱好者并没有得到平等的对待，甚至的毫不关心的态度，相对于潜在的商单，他们更喜欢数着现在的钱。同样很多传统做 NAS 的厂家售后也跟不上，要么是响应时间等很长很长，或者给到完全不靠谱的结论甚至一本正经的一读乱回。需要注意的是，这里不是一棒子打死所有的云厂商和 NAS 厂家，而是当你遇到紧急的问题时候，还是有很高的概率遇到这样的冷处理。所以我们常开的一句话玩笑话：迁走。
现在觉得，如果不是生产环境必须要对互联网公开或者强制遵循一些安全上的 0 信任原则，比如 POC 环境或者个人环境，用懒猫就完全足够了，还要什么云服务器，那么贵又那么脆。
曾经曾经——我也是云计算忠实的拥护者。。。。。。
一直想写一本容器小书，真好懒猫基本都做了容器化，所以把这部分分享出来。不同的是，懒猫微服中使用 pg-docker 来替代 docker 命令，使用 dockge 来执行 docker-compose。以下讲解以标准 docker 为主，这样子既学会了 docker 知识，也能够在懒猫微服上启动 Docker 服务。
镜像旅馆的旅途告一段落，小李的下一站是容器部落。
老周牵着他走过一条闪烁着数字光芒的通道，一排排运行中的应用像帐篷一样排列着。有人在调试日志，有人在重启服务，还有人用 bash 正在某个容器里“打补丁”。
老周说：
“镜像只是静态的模板，容器才是它们的生命。容器是镜像运行出来的真实世界。”
| 项目 | 镜像（Image） | 容器（Container） |
|---|---|---|
| 类比 | 模板、配方 | 实际的运行实例 |
| 特性 | 只读 | 可读写 |
| 作用 | 用来创建容器 | 实际运行中的程序环境 |
| 状态 | 不运行 | 可运行、停止、销毁 |
小李想运行他的 Flask 应用镜像。
老周告诉他：
“运行镜像的命令是
docker run，容器就像是用镜像盖起来的一顶帐篷。”
1 | docker run my-flask-app |
但程序一执行完就退出了。小李困惑。
老周解释：
“容器会在主进程结束后自动退出，比如
CMD ["python", "main.py"]一旦结束，容器就结束了。”
1 | docker run -d --name flask-app -p 5000:5000 my-flask-app |
解释：
-d：detached 模式，后台运行--name：给容器取个名字，方便管理-p 宿主端口:容器端口：端口映射，把容器内部 5000 暴露到外部小李可以在浏览器里访问
http://localhost:5000，服务在跑！
1 | docker run -d -e ENV=production my-flask-app |
在容器内可通过 os.environ['ENV'] 访问。
1 | docker run -d --restart=always my-flask-app |
可选策略：
| 策略名 | 说明 |
|---|---|
no | 不自动重启（默认） |
on-failure | 出错时重启 |
always | 永远重启 |
unless-stopped | 除非人为停止 |
老周说：“运行中的容器就像是火堆，你得学会看它们是否还在烧。”
1 | docker ps |
如果想看所有容器（包括已退出的）：
1 | docker ps -a |
输出示例：
1 | CONTAINER ID IMAGE STATUS NAMES |
1 | docker stop flask-app |
1 | docker start flask-app |
1 | docker restart flask-app |
⚠️ 容器停止后并不会删除，除非显式用
docker rm
有一次小李发现容器里缺了个配置文件，他想进去看看。
1 | docker exec -it flask-app /bin/bash |
-i：保持输入-t：分配终端/bin/bash：使用 bash shell（Alpine 镜像可能要用 /bin/sh）现在他能像 SSH 进服务器一样，在容器里操作文件、日志、环境变量。
某天应用崩溃了，小李要调日志。
老周提醒他：“容器日志直接走标准输出和错误输出。”
1 | docker logs flask-app |
可以加参数看最近内容：
1 | docker logs --tail 100 flask-app |
实时滚动输出（调试很有用）：
1 | docker logs -f flask-app |
小李尝试重建容器时，系统提示名字重复。
老周告诉他要先删除原来的：
1 | docker rm flask-app |
如果容器还在运行，先 stop 再 rm，或直接强制：
1 | docker rm -f flask-app |
| 操作 | 命令 |
|---|---|
| 创建 + 运行容器 | docker run |
| 后台运行 | docker run -d |
| 设置名字 | docker run --name name |
| 设置端口映射 | -p 外:内 |
| 查看容器 | docker ps [-a] |
| 停止容器 | docker stop name |
| 启动容器 | docker start name |
| 重启容器 | docker restart name |
| 删除容器 | docker rm [-f] name |
| 查看日志 | docker logs [-f] name |
| 进入容器 | docker exec -it name /bin/bash |
老周布置了一个练习：
“请你写一个脚本，构建镜像，运行容器，设置环境变量和端口，再用日志确认 Flask 成功启动。”
小李完成如下步骤：
1 | docker build -t flask-test . |
容器退出时，可以用 docker ps -a 查看 STATUS 栏：
Exited (0)：正常退出Exited (1)：出错退出Up：正在运行调试时很有用。
小李现在已经能够用容器完成：
他看着容器部落中灯火通明的帐篷，知道自己终于从一个“只会打包镜像”的新人，成长为能驾驭容器生命周期的工程师。
老周拍拍他肩膀说：
“你已经能掌控容器的生死了，下一步——掌控它们的数据。”
好嘞，我们来拓展第三章《容器部落生活》，新增三大实战内容：
🚀 Nginx 容器部署
🔗 多个容器配合运行（应用 + 数据库）
🩺 容器的服务探针（健康检查）
这部分会继续以故事+实战命令+讲解的方式展开，帮助你更贴近真实工作中的容器部署流程。
小李想搭个静态站点测试，老周给他出了一个练习：
“用 Nginx 容器部署一个 HTML 网站，只通过 Docker 完成。”
1 | nginx-site/ |
index.html 示例：
1 |
|
1 | FROM nginx:alpine |
✅ 把自己的网页文件覆盖掉默认首页。
1 | docker build -t nginx-site . |
打开浏览器访问 http://localhost:8080，小李看到页面显示成功，笑得像个孩子。
接着老周出了第二个任务：
“把你的 Flask 应用和一个 MySQL 数据库用两个容器跑起来，实现数据连接。”
1 | docker network create flask-net |
1 | docker run -d --name my-mysql \ |
假设 Flask 连接数据库时使用：
1 | host = 'my-mysql' # 容器名就是主机名 |
启动命令：
1 | docker run -d --name flask-app \ |
🔗 容器间在同一个网络中，通过名字直接通信，像局域网一样！
docker-compose（下一章会详细讲）老周问小李：“如果你的服务挂了，但容器还在运行，你怎么知道？”
小李摇头：这不就是“僵尸容器”吗？
老周笑了：
“那就给它加一个健康探针（HEALTHCHECK），定期检测服务状态。”
修改 Dockerfile：
1 | HEALTHCHECK --interval=30s --timeout=5s --start-period=5s --retries=3 \ |
在 Flask 代码中添加一个健康检查路由：
1 |
|
构建镜像，运行容器后，通过命令查看健康状态：
1 | docker inspect flask-app | grep -i health |
输出示例：
1 | "Health": { |
如果 /health 接口返回失败状态码，容器会标记为 "unhealthy"，可配合自动重启策略联动修复。
| 场景 | 命令 / 技术 |
|---|---|
| 部署静态站点 | Nginx + COPY index.html |
| 容器间通信 | docker network create + --network 参数 |
| 多容器组合 | 应用容器连接数据库容器 |
| 服务探针 | Dockerfile 添加 HEALTHCHECK，应用实现 /health |
| 探针状态查看 | `docker inspect 容器名 |
小李站在容器部落的山丘上，看着成百上千个容器像城市灯火一样运转。
Nginx 做前端代理，Flask 作为后端逻辑，MySQL 管理数据，每个服务都是一块积木，有秩序、有协作。
老周淡淡说：
“这只是单机的容器调度，真正的战场——在云上。”
小李的眼里闪起光芒：“那我下次要学的就是——Compose，K8s，还有 CI/CD，对吧？”
老周点头：“没错，下一站——数据卷与共享、Compose 编排，再之后……你就要去打云原生的战了。”
]]>核心思路
- 独立
daemon.json指定专属数据目录 / Socket- 一个包装脚本
dev-docker让你照常敲docker命令- 需要时随时启用，不用时一条命令即卸载
我目前是在 root 目录下新建了一个 dev 目录，新的容器所有数据都在这个目录下。
1 | . |
提示：
docker.sock、docker.pid会在启动时自动生成到dev/里。
daemon.json这个是主要的文件，定义了 dev-docker 的数据目录，以及命名空间的隔离。
1 | # 先拿到绝对路径，避免 dockerd 报相对路径错误 |
使用 dockerd 指定配置文件启动 dev-docker，然后放在后台进行。
1 | sudo dockerd --config-file=$DDIR/daemon.json --log-level=info & |
执行之后得到如下的结果：
1 | INFO[2025-05-20T12:55:02.072949048Z] detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf |
dev-docker 包装脚本这个脚本就是仿照懒猫微幅其他的 docker 实现：
1 | cat > ./dev-docker <<'EOF' |
设定DOCKER_HOST=unix://$(realpath ./dev/docker.sock)，然后用 exec docker "$@" 把收到的全部参数原封不动交给真实的 docker 命令执行。
然后就可以正常使用了：
1 | ./dev-docker ps |
系统自带的 docker 仍在 /var/run/docker.sock 上工作，互不打扰。
dev-docker 放入全局 PATH如果想全局生效，运行下方命令。但注意：懒猫微服重启后 /usr/local/bin 会被还原。”
1 | sudo install -m 755 ./dev-docker /usr/local/bin/ |
1 |
|
启动脚本：
1 | chmod +x init-docker-dev.sh # 赋可执行权限（若脚本是下载的） |
运行完脚本后，后续就在当前目录直接敲 ./dev-docker <command> 即可；
如果之前已将 dev-docker 安装到 PATH，全局也可以直接 dev-docker ps
脚本执行记录如下：
1 | 🎉 Dev Docker 已就绪，使用 ./dev-docker 访问！ |
sudo ./dev-docker info查看信息：
1 | sudo ./dev-docker info |
./dev-docker pull ubuntu 下载 images：
1 | ubuntu@ip-172-31-29-78:~$ sudo ./dev-docker pull ubuntu |
检查 docker 版本：
1 | ubuntu@ip-172-31-29-78:~$ dev-docker --version |
1 | ps aux | grep dockerd |
1 | pkill -f './dev/daemon.json' |
清除数据
1 | rm -rf ./dev # 删数据目录 |
再多一套 Docker，不是为了炫技，而是给开发或者测试环境一个“随时可重置、天然隔离、低成本回收”的保险箱。学会这一招，你就能在懒猫微服乃至任何 Linux 服务器上，放心大胆地尝鲜新内核、新 runtime，甚至复刻生产 bug —— 然后一句 pkill + rm -rf dev/，世界瞬间清爽如初。祝玩得尽兴！
一直想写一本容器小书，真好懒猫基本都做了容器化，所以把这部分分享出来。不同的是，懒猫微服中使用 pg-docker 来替代 docker 命令，使用 dockge 来执行 docker-compose。以下讲解以标准 docker 为主，这样子既学会了 docker 知识，也能够在懒猫微服上启动 Docker 服务。
自从小李用 Docker 成功打包并运行了自己的 Flask 项目，他的开发效率飞快提高。
某天，老周带他来到一座巨大的数字建筑——Docker 镜像旅馆。
“这是你所有镜像的家，”老周说，“也是全球程序员共享旅程资源的中转站。”
镜像旅馆里，层层叠叠地存放着成千上万个镜像，就像一栋模块化的高楼大厦。
老周告诉小李：
“镜像（Image）其实是一个只读的分层文件系统。你写的每一条 Dockerfile 指令，都会构成一层 Layer。”
比如这个简单的 Dockerfile：
1 | FROM python:3.11-slim |
对应的镜像层如下：
FROM → 拉了一个基础镜像层（Python 3.11）WORKDIR → 添加一个设置工作目录的 LayerCOPY → 拷贝代码文件的 LayerRUN → 安装依赖的新 LayerCMD → 容器入口（不是 Layer，但存配置）💡 小知识：Docker 会尽量缓存和复用前面的 Layer，节省时间和存储。
小李打开终端，开始探索这些镜像的日常操作。
1 | docker images |
输出示例：
1 | REPOSITORY TAG IMAGE ID CREATED SIZE |
解释：
REPOSITORY：镜像名TAG：标签（版本号）IMAGE ID：镜像唯一标识符SIZE：镜像大小1 | docker history my-flask-app |
1 | docker rmi my-flask-app |
（⚠️ 若有容器在运行该镜像，需先停止并删除容器）
老周指了指旅馆大堂里的一个巨大电梯：
“这是 Docker Hub，全球最大的镜像共享仓库。”
在这里，小李能下载成千上万的开源镜像，也能上传自己的。
1 | docker login |
（需要先注册账号）
1 | docker pull nginx |
这会从 Docker Hub 拉取最新版本的 nginx 镜像
1 | docker pull redis:6.2 |
如果 docker run/pull 有问题，那么可以通过
lzc-cli appstore copy-image your-images来使用懒猫的镜像仓库。
（相当于拉取 redis 仓库中 tag 为 6.2 的镜像）
1 | docker tag my-flask-app yourdockerhubname/my-flask-app:1.0 |
老周问：“小李，你知道为什么镜像都有个 :latest 吗？”
小李说：“这是默认版本号吧？”
“对，但我们不能依赖它。开发、测试、生产应使用明确版本号，比如 1.0、20240321 等。”
Docker 镜像是通过 tag 来区分版本的：
1 | docker build -t myapp:1.0 . |
你可以为同一个镜像打多个标签，对应不同场景使用。
小李注意到镜像越来越大了，占了很多硬盘空间。
老周给了他几点建议：
使用轻量级基础镜像：
python:3.11-slim 代替 python:3.11合并
1 | RUN |
命令，减少层数：
1 | RUN apt update && apt install -y git && rm -rf /var/lib/apt/lists/* |
删除临时文件：
多阶段构建（进阶）：
后来小李想把自己的镜像传给另一位没有 Docker Hub 的同事。
他用到了镜像导出与导入：
.tar 文件：1 | docker save my-flask-app > myapp.tar |
1 | docker load < myapp.tar |
镜像打包成离线文件，便于携带与备份。
小李很好奇，镜像到底长什么样？
老周教他运行容器并进到里面：
1 | docker run -it --rm my-flask-app /bin/bash |
这样他就能直接进入容器的 Linux 环境，像在服务器上一样查看文件结构：
1 | ls / |
他终于明白，每个镜像就像是一个“静态快照”，而容器才是“它的动态运行副本”。
| 操作 | 命令 |
|---|---|
| 查看本地镜像 | docker images |
| 构建新镜像 | docker build -t name . |
| 删除镜像 | docker rmi 镜像名 |
| 下载镜像 | docker pull 镜像名[:tag] |
| 上传镜像 | docker push 镜像名[:tag] |
| 镜像打包导出 | docker save > xxx.tar |
| 镜像导入还原 | docker load < xxx.tar |
| 镜像历史层查看 | docker history 镜像名 |
小李现在拥有了多个镜像，搭配不同的版本、依赖、语言，像积木一样可以快速组合各种环境。
“这就像 Minecraft 的世界地图，每张都是一个镜像。”小李说。
老周点点头：“没错，镜像只是开始，真正的冒险——是容器运行起来后的世界。”
.tar 进行离线传输build、pull、push、rmi、tag、history有一次，小李需要构建一个使用 npm 打包前端、Python 启动后端的项目。打包工具很多、依赖也重，他担心镜像太大。
老周说：“你要学会多阶段构建（multi-stage build），把构建阶段和运行阶段分开。”
多阶段构建的目标是：编译用谁都行，最终镜像要最小。
1 | # 第一阶段：使用 node 构建前端 |
小李一测试，镜像体积从 300MB 降到 25MB，部署速度快了 10 倍！
.dockerignore：镜像防垃圾机制构建时，小李发现镜像中夹杂了 .git、node_modules、__pycache__……
老周摇头道：“你忘了 .dockerignore 文件。”
就像 .gitignore 一样，.dockerignore 告诉 Docker 哪些文件在构建镜像时要排除。
1 | __pycache__/ |
这个文件放在 Dockerfile 同目录下，能显著加快构建速度和减小镜像大小。
当公司禁止使用 Docker Hub 时，小李开始尝试搭建自己的镜像库。
老周带他部署了一个本地私有镜像仓库（基于 Docker 官方镜像）：
1 | docker run -d -p 5000:5000 --restart=always --name registry registry:2 |
现在他可以：
推送到私库：
1 | docker tag myapp localhost:5000/myapp |
拉取镜像：
1 | docker pull localhost:5000/myapp |
适合公司内部使用，搭配 Nexus、Harbor 可实现更完善的权限、审计、镜像管理等功能。（比如懒猫的 copy-image）
如果小李的镜像出错了，他可以通过两种方式“探测”镜像内部：
1 | docker run -it myapp /bin/bash |
（如果 bash 不存在，可以用 /bin/sh）
1 | docker exec -it container_id /bin/bash |
通过 ls、cat、which、env 命令，可以检查：
pip install 是否安装成功？小李曾在 Dockerfile 里写了：
1 | ENV DB_PASSWORD=123456 |
老周当场拍桌：“你这是把钥匙写死进容器了！”
最佳做法：
.env 文件 + --env 参数）docker secret 或 KMS 管理--secret 机制加密构建时参数（高级用法）小李准备上线，他开始给镜像打各种 tag：
1 | docker build -t myapp:1.0.0 . |
老周说：
“tag 是镜像的版本名，不要用
latest作为生产环境唯一标识。”
推荐命名规范：
| 标签 | 含义 |
|---|---|
myapp:1.0.0 | 语义化版本控制 |
myapp:20240324 | 构建时间戳 |
myapp:prod | 环境标识 |
myapp:feature-login | 功能分支测试 |
有时候构建镜像时，小李发现修改了某个文件，Docker 却好像没更新。
老周点拨他：“那是缓存搞的鬼。”
1 | docker build --no-cache -t myapp . |
Docker 会从上到下按顺序缓存。如果把变化频繁的文件 COPY 太早，就会导致缓存失效：
1 | COPY requirements.txt . # OK，变动少，适合先复制 |
✨ 技巧：越是稳定的文件，越早 COPY，利于缓存复用。
| 技术点 | 命令 / 说明 |
|---|---|
| 多阶段构建 | FROM ... AS builder + COPY --from=builder |
| 忽略文件 | .dockerignore 文件 |
| 镜像上传私库 | docker push localhost:5000/myapp |
| 开启 BuildKit | DOCKER_BUILDKIT=1 docker build ... |
| 进入镜像内调试 | docker run -it 镜像 /bin/bash |
| 镜像版本管理建议 | 避免乱用 latest，使用语义化 tag |
| 跳过缓存构建 | docker build --no-cache ... |
小李站在镜像旅馆的屋顶，看着一层层高楼像乐高积木一样堆叠而起。
他感到激动——他已经不再为“部署”苦恼，而是拥有了一个随时可打包、可还原的开发宇宙。
老周说：“你的旅程才刚刚开始，容器的世界比镜像更复杂。”
]]>说干就干。
在懒猫论坛上看玄兴梦影的文章，《懒猫微服无缝连接你所有的设备》和《懒猫微服助我生活工作穿梭无忧》这两篇让我受益颇丰。主要是借用懒猫微服的中继服务，用来自建 Rust Desk，还有 RDP 到局域网的其他设备上。
先说 Rust Desk，这是一度被推举为 Todesk 的替代的软件，在懒猫上安装服务端拿到域名和密钥，然后在客户端上填入就可以了,具体操作可以看前面推荐的文章，里面有细致的讲解。
我的需求就是，在外边除了能够访问家里的微服之外，还访问其他的设备，比如群晖，威联通，甚至 windows。这样子以后带个 Ipad 出门就可以了，MacbookPro 的受害者表示笔记本太沉了。
所以这本质上是一个异地组网的问题，在上一个版本的 HomeLab 中是使用的蒲公英的 P5 盒子，这东西卖点是旁路由，直接 POE 接入局域网就好了，还能共享打印机。但是吧，商业产品还有很多限制，比如组网只能三个设备，带宽有限制，在多次的和售后拉扯而且案例没有在规定时间内回复也没有按照服务水平协议赔偿之后，索性退坑。
还有一次很玄学的事情，蒲公英盒子升级固件和家里跳闸的时间高度重合，开案例询问之后，传了日志，客服也只是贴了文档表示绝对不会有电流突增的问题，再问就再也没有回复了。然后会自动结单给五星好评，还不能重新打开继续问问题。
蒲公英在国内是没有什么竞品的，论企业服务远远不及思科之类的产品，而个人用户又一种丝毫不在意的态度。而且会一直推荐买最新的 X5 PRO，而卖完之后改完静态路由不能组网，客服又一副到底你懂不懂的样子。哎，蒲公英是彻底疯转黑了。那不买他们硬件用 OrayOS 呢？请先看免责声明：
所以一直想找其他 SD-WAN 或者异地组网的方案。主要需求嘛，就是既能从外面访问，也能转发其他的设备的流量，能做权限控制就更好了。
懒猫微服目前没有自己的虚拟机系统，所以是用的 webvirtcloud，但是商店里也有很多上架的系统，比如直接点点鼠标就可以开 windows 虚拟机了，这个有点云计算的味道了。不过就是我用的机械硬盘，开 windows 实在是有点差强人意。所以后面弄了一个局域网的机器专门拿来跑 windows，就是后面要提到的局域网转发。
从商店下载的 app 都有一个特定的域名。
1 | <应用名>.<设备名>.heiyu.space |
以商店里的虚拟机为例，直接在 RDP 里输入这个机器的 URL 就就行，以前的 Windows remote desktop 现在改名叫做了 Win APP，同时也能在国内的 app store 上搜索到了。（前提登录懒猫 APP）
首先设置密码，虽然没有密码能够打开远程登录，但是实际怎么都连不上。
然后在系统设置打开远程桌面，在上面那个搜索栏的中直接搜就好。 然后我们就可以连接了。
那两台登录微服的设备如何互联呢？这里有个很赞的工具，可以获取客户端的信息。商店搜索：懒猫微服在线设备获取
在 APP 中我们能够看到每个设备的域名：（隐私保护，我这里已经隐去）
那在脑洞一下，是不是可以做到之前说的旁路由的效果呢？
这里有个局域网转发工具。
猜测可能是 iptables 一类转发的吧。可以把局域网的设备映射出去（不需要安装懒猫客户端），还要什么旁路由。
现在远程连接的是我这台局域网一台刚刚装好的 windows，不需要在被控端安装安装任何软件（包括懒猫 APP），看到也能通过懒猫的域名组网了，开心～
内网穿透有了！
旁路路模式转发有了！
出门带 ipad 不用带笔记本了～
]]>本文仅代表个人视角对懒猫 Docker 的拆解分析，内容为基于现象的倒推推测，不代表懒猫官方实现方式。
拿到任何 NAS 的第一件事是开启 SSH 功能，第二步就是用 Docker 启动容器。
懒猫微服这个 docker 还不太一样，一个有三个 Docker：
docker : 运行系统组件
pg-docker： 普通的 docker，让我们拿来玩
lzc-docker：运行懒猫商店的 docker
我们先来看看这三套 docker 引擎跑了些什么，从 ps 看起：
1 | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
这里可以看到，系统级组件都跑在默认的 docker 下。
1 | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
pg-docker实际上就是日常部署、测试容器最常用的那一套运行时环境， Dockge 默认连接的运行时也是这个。只是这里为了区分系统 docker 做了改名，playground 就是随便玩的意思。
1 | lzc-docker ps |
这个是懒猫商店的 Docker，实测在客户端中停止应用是是把对应的 docker 删除了，无论是从docker ps -a | grep auth还是可视化工具看来。这也很符合使用容器的习惯，不需要的时候就删除，随用随启动，但是数据仍然还在。
我们再来看一下版本，都还是一样的。所以这个就很有意思了。
1 | lzcbox-029c588e ~ # docker --version |
再看看存储后端，那是不是有什么魔改呢？看的出来后端都是 containerd。
1 | lzcbox-029c588e ~ # docker info | grep -i 'Runtimes\|Default Runtime' |
甚至连 containerd 的版本都一样
1 | # docker info | grep -i "containerd" |
一开始以为是魔改看了下我的 mac 运行的 Orbstack 的配置，好像也没啥差别。
1 | docker info | grep -i 'Runtimes\|Default Runtime' |
既然三个 docker 都出奇的一致，到底是类似命名空间的隔离嘛？
1 | lzcbox-029c588e ~ # which docker |
这就可以发现问题了，docker 是原来的 docker，但是 pg-docker 和 lzc-docker 是封装的脚本，来看一下：
所以我们可以得出一个关键点：懒猫并不是运行了三套完全独立的 Docker 服务，而是通过 shell 脚本封装，复用同一个
docker客户端，切换不同的 socket 实现了“环境隔离”。这个脚本的作用相当于把pg-docker当成docker命令使用，还自动附带了环境变量DOCKER_HOST=...。
1 | lzcbox-029c588e ~ # cat $(which pg-docker) |
这设置了 DOCKER_HOST 环境变量，使得之后执行的 docker 命令会连接到 /data/playground/docker.sock 这个 Unix Socket，而**不是默认的 /var/run/docker.sock**。
exec 是一个 shell 内建命令，它会用新的进程替换当前脚本的进程。
"$@" 表示把脚本接收到的所有参数（比如 pg-docker ps -a）原样传递给 docker 命令。
之前想上架一个 Docker 可视化工具用来，但是总不知道需要映射哪个 docker.sock，这下子全都清楚了，有了这个就能在 docker 里使用宿主机的 Docker API 了。
当然与之对应的还有 daemon.json,除了用来改代理之外，我们还能修改这些东西：
1 | lzcbox-029c588e /data/playground/data # cat /lzcsys/var/playground/daemon.json |
这样多个 Docker 环境就能共存了，例如：
/var/run/docker.sock/data/playground/docker.sock这么设置好之后可以快速切换上下文，而不用每次都手动设置 DOCKER_HOST。
在我开发的容器可视化面板总，看到已经可以指定 docker sock 作为连接了,参考：
1 | services: |
从实际查找结果来看，懒猫为三套 Docker 引擎配置了不同的 daemon.json 文件和运行时环境：
/etc/docker/daemon.json/lzcsys/var/playground/daemon.json/lzcsys/etc/docker/daemon.json1 | sudo find / -type f -name daemon.json 2>/dev/null |
每个配置文件中都指定了独立的：
data-rootexec-rootpidfilehosts（即 sock 文件路径）1 | # 默认的docker引擎 |
懒猫微服总会给我惊讶，除了极客风格的外壳，性能突出的硬件外，里面的软件设计也同样优秀，这个设计让我对 docker 有了更加深刻的认识。
三套 docker 共存不是表面上的魔改，而是通过 containerd 的 namespace 配合脚本封装，在容器之上再抽象一层运行时，把 playground、系统和商店隔离成三界，却又共用一套内核，很好玩。
]]>使用 root 账号登录 AWS 管理控制台
点击右上角账号名称
选择”安全凭证”选项
然后会收到邮件提醒：
如果遇到这个报错，那么重新登陆之后再重复前面的步骤：
1 | To complete this action, please ensure that you are authenticated with an MFA device that is enabled for this user. |
一直想写一本容器小书，真好懒猫基本都做了容器化，所以把这部分分享出来。不同的是，懒猫微服中使用 pg-docker 来替代 docker 命令，使用 dockge 来执行 docker-compose。以下讲解以标准 docker 为主，这样子既学会了 docker 知识，也能够在懒猫微服上启动 Docker 服务。
小李是一名后端工程师，刚完成一个用 Flask 编写的内部管理系统。他信心满满地将代码提交，交给测试工程师老赵部署。
可没想到——
“报错了！你是不是少传文件了？”
“我这边 Python 是 3.6，怎么你这代码用了
match case？”“你数据库呢？你 Redis 配了？环境变量在哪？”
这一刻，小李陷入了一个叫「部署地狱」的世界。
这个世界里，每一台服务器都是独一无二的“宠物”，需要手动配置、手动部署、手动踩坑，稍有不慎就会陷入版本冲突、依赖缺失、环境不一致的深渊。
小李心里想：有没有一种办法，能让我把代码和环境一起打包起来，无论在哪运行都能保持一致？
在公司茶水间，小李邂逅了一个带着黑框眼镜的大叔，大家都叫他老周。
老周是个技术老炮，在各种部署大灾难中杀出血路。他听完小李的吐槽后，轻轻地推了一份文档过来，只写了五个字母：
Docker
“这是个魔法容器，”老周说，“把你代码和环境都打包进去，哪怕放在火星，也能跑。”
“以后别再‘它在我电脑上可以跑’了，Docker 能让所有环境变得一致。”
小李的眼睛亮了。
Docker 是一个开源的容器化平台，它允许开发者将应用及其所有依赖打包成一个“容器”，保证在任何平台上都可以一致运行。
你可以把 Docker 想象成：
程序员的打包箱子：把你写的程序、环境、库、配置都放进去，打包成一个“镜像”；
程序员的快递服务：运行镜像就像打开快递，内容和你寄出时一模一样。
☑️ 一句话总结：Docker 解决了“在我电脑上能跑”的问题。
老周拍了拍小李的肩膀，说：“先装起来，动手最重要。”
1 | docker --version |
如果看到 Docker 的版本信息，说明安装成功。
1 | sudo apt update |
🔐 建议将当前用户加入 docker 组，以免每次都要用 sudo：
1 | sudo usermod -aG docker $USER |
| 概念 | 说明 |
|---|---|
| 镜像（Image） | 应用和其依赖的静态快照模板（如：打包好的 Python 环境 + Flask 项目） |
| 容器（Container） | 镜像运行出来的实例，是真正“活着”的程序 |
| Dockerfile | 编写镜像的“配方”，定义如何构建镜像 |
| Docker Hub | 类似 GitHub 的公共镜像仓库，可上传/下载别人做好的镜像 |
docker 命令 | Docker 的主命令工具，用于操作镜像、容器、网络、卷等 |
老周指导小李敲下第一行命令：
1 | docker run hello-world |
如果 docker run/pull 有问题，那么可以通过
lzc-cli appstore copy-image your-images来使用懒猫的镜像仓库。
这个命令会做三件事：
hello-world 镜像（如果本地没有）这是验证 Docker 是否正常运行的“点灯测试”。
老周笑着说：“现在，把你那个 Flask 管理系统也丢进 Docker 试试。”
小李在项目根目录下写了一个 Dockerfile：
1 | # 使用 Python 官方基础镜像 |
1 | docker build -t my-flask-app . |
1 | docker run -p 5000:5000 my-flask-app |
现在访问浏览器 http://localhost:5000，你的项目上线了！
docker ps 查看运行中容器，docker images 查看已有镜像；.dockerignore 文件忽略不想加入镜像的文件，比如 .git 和日志。这次，小李把打好的镜像发给了测试老赵：
1 | docker run -p 5000:5000 my-flask-app |
老赵只运行了一行命令，项目便神奇地跑了起来。
“不改配置？不用装 Python？数据库也连上了？”
“你这是什么魔法！”
小李笑了笑，第一次感觉部署是件简单的事。
| 技术点 | 命令 |
|---|---|
| 安装 Docker | Mac/Win 下载 Docker Desktop / Ubuntu 安装 docker.io |
| 查看版本 | docker --version |
| 运行测试容器 | docker run hello-world |
| 编写 Dockerfile | FROM / COPY / RUN / CMD |
| 构建镜像 | docker build -t name . |
| 运行容器 | docker run -p 宿主:容器 镜像名 |
声明：炫技篇不是最佳实践，只是为了记录过程和那颗折腾的心。虽然很多时候可以用钱来升级或者多忍一忍就好了。但是折腾的心始终是不安分的，技术在职场中证明不了什么，但是在生活中可以。当晦涩的理论不仅仅存在于书本，才能给我们带来更大的价值。这个过程中能够找到我们到底是为了什么才需要这项技术，问题的痛点，以及这技术的前世今生。。。。。。
前些天给老旧的车载导航升级了 WIFI 功能，大致就是出厂的时候锁了 wifi 的驱动和 UI，然后通过 ADB 解锁的，然后通过路由器 Mesh 升级了老旧的 APP 以及导航数据，这次又带来了全新的功能，给普通车机升级 Carplay。
毕竟我的初衷，就是想在车机上安装懒猫 APP 而已啊。
下载懒猫微服 APK，通过 U 盘导入安装，报错：解析错误，解析软件包时出现问题。
于是和懒猫相关技术进行确认，很快 CEO 给到了答复，目前只支持比亚迪和华为。毕竟国产车嘛，路子野一点也正常。
那我如果不用安卓，换 Carplay 呢？是不是就能用 IOS 的客户端直接投过去了？
开始改 Carplay。
车载导航是当时赠送的，安卓 6.0。朋友推荐说可以购买 Carplay 盒子，于是疯狂搜索，现在的 Carplay 盒子分为两种。
我的安卓车机没有 Carplay APP，方向盘也没有语音控制按钮。所以一开始能不能支持 Carplay，我是比较有疑问的。直到搜到了一篇夸赞车连易的帖子，大概说是最早做这个方向的公司，产品比较稳定一类的。
于是买回来调试，需要先安装他们的 autokit 软件检测（买之前需要用 Iphone 检测），这个 APP 后续当 Carplay APP 使用。（这里有个小插曲，之前 adb 调试的时候在改了工厂模式，开了 USB 调试，导致后来 USB 无法识别任何设备，包括 U 盘，2.4G 发射器，手机，以及 Carplay 盒子）对照之前的照片，关了就好了。然后我就拥有了人生第一台 Carplay 车机，盒子一点不烫，就是手机哗哗掉电。
开心之余还不忘记去找懒猫 APP，屏幕上有钉钉，百度网盘，网易云，甚至连 Home Assistant 都有？那我的懒猫微服 APP 呢？原来是 Apple 的白名单限制，美其名曰为了安全。GPT 搜下了，基本上除了导航和音乐一类的设备其他都没有了。那我高速服务区追个剧？好歹让投个屏嘛。。。。。。
同时和微服以及 Carplay 盒子的厂家确认，得到了一份寥寥无几的 APP 名单。
梦碎？
GPT 的解释如下：
以下内容基于 Apple 开发文档（2024 年最新版）及最近一次 iOS 18.4 更新的公开信息整理而成，可作为「CarPlay 现阶段 官方 支持的 App 类型、代表性应用，以及常见限制」速查表。(Apple Developer)
| 类别 | 典型代表 App | 主要交互模板 | 备注 |
|---|---|---|---|
| 导航 | Apple 地图、Google Maps、Waze、Gaode/高德 | 地图、仪表盘、列表 | iOS 18.4 起可设 默认导航（EU 地区率先落地）(The US Sun) |
| 音频 | Apple Music、Spotify、网易云音乐、Podcast、Audible、DS Music（Synology） | 播放中、网格、列表 | 仅音频；禁止歌词滚动、视频封面等会分散注意力 |
| 通信 | 电话、信息、WhatsApp、钉钉、Teams | 列表、语音 | 文本内容不得直接显示，只能通过 Siri 朗读 |
| 停车 | EasyPark、停简单 | 列表 | 提供空位、计费等信息 |
| EV 充电 | Tesla、ChargePoint、小桔充电 | 列表、地图 | 可筛选功率、空闲桩等 |
| 加油 / 加氢 | BPme、壳牌加油 | 列表、地图 | 仅提供站点 & 价格；支付流程需遵循「停车后才允许」规则 |
| 快餐外卖 | Dunkin’、星巴克 | 列表 | 只能选择常用餐点并一键复购，禁做复杂自定义 |
| 驾驶辅助 / 任务 | 扫盲测试、行车记录提示类 | 网格、信息 | 聚焦安全提醒、里程统计等（不含 ADAS 改装） |
车企自家 App（空调、座椅、360 环视等）属于「Automaker Apps」，与上表并列但须由车厂提交。(Apple Developer)
| 场景 | 限制要点 | 开发侧原因 |
|---|---|---|
| 视频/娱乐（Netflix、哔哩哔哩） | 行车安全：禁止播放分散注意力的可视内容 | CarPlay 模板不提供视频区域；审核会拒绝 |
| 文件管理（ES 文件浏览器、NAS 探索） | 无对应类别；操作路径过复杂 | 无可用模板且易诱导司机操作 |
| 社交媒体（微博、X、抖音） | 不得显示滚动 Feed、评论等 | CarPlay 指南明令「No social networking」(Apple Developer) |
| 游戏 / 浏览器 | 驾驶分心 & 没有类别 | 同上 |
| 维度 | 具体表现 |
|---|---|
| 设备要求 | iPhone 6s 及以上（iOS 17+ 建议），Lightning 有线或支持无线 CarPlay。 |
| 同时运行数量 | iOS 18.4 支持「三排图标」；实际显示取决于车机分辨率。(The US Sun) |
| 地区差异 | 某些导航/支付/餐饮 App 仅在特定国家可上车，例如中国区暂不开放「Apple 钱包加油」。 |
| 多任务 | 非导航类 App 在后台仅获有限音频/定位权限；切回主屏超过 8 分钟或手动关闭即结束会话。 |
| 问题 | 解答 |
|---|---|
| 能在 CarPlay 打开 NAS 上的影片吗？ | 不行，现阶段只支持「音频类」DS Music；视频需停车使用原车 USB/HDMI 或车企自带系统。 |
| 想在车机上用 VSCode、ES 文件浏览器？ | 属于生产力 / 文件管理场景，CarPlay 无对应类别，无法过审。 |
| 越狱或使用 CarBridge 能装任何 App 吗？ | 理论可行但高风险：系统不稳定、Apple Pay 安全受损、保修被拒，不建议在主力机尝试。 |
小红书上搜到了 DS audio 的攻略，竟然是群晖套件？评论区还有人推荐 DS music，颜值很高。下载之后我也很喜欢。
不就是群晖嘛，这年头谁还没一个黑群晖了。公网 IP 不定时被封端口，那懒猫转发了解一下？
于是把群晖的端口映射出来，就在 APP 中可以远程连接使用了，这不比 Synology QuickConnect 还省事嘛。。。。
各类软件测试如下
最后喜欢的还是 DS music，功能正常还好看啊。
除了 DS 系列，好像 Q 系列也行，不过吃灰很久很久了。（具体连接待测试）
用懒猫微服解决了公网转发的问题，再也不担心被运行商封端口了，还有车载大屏（除了有点掉帧），也算圆了一个梦吧。
你的车有 Carplay 吗？
]]>故事的背景是这样的，去参加了 AWS 的活动给的账户强制开 MFA，但是我们还想团队内部 share 使用，于是产生了这个需求。
登录到 AWS 的控制台强制开了 MFA，而且在第一次注册的时候强制绑定多因子验证。这也就意味着，其他人如果想登录这个账户就得随时 call 我，然后我去发给他数据验证码，这实在很不方便，所以想到了共享的 MFA 的需求。
头几天逛商店看到的，觉得项目有点意思就下载了，没想到这么快用到了。懒猫商店，一键部署很方便，当成 Saas 服务来用，完全不考虑部署运维的事情。
之前给小伙伴开了懒猫微服的账户，共享了 planka 来看项目进度，这次把 2fauth 的权限也添加给他。
首先我这边先注册管理员的账户，默认是登录页面，需要切换一下。
登录之后会提示绑定一下这个账户的 MFA，我就是为了不在手机上安装 MFA 软件才用这个的，就不要套娃了。反正外面还有懒猫的验证系统，那个还有 TLS 加密，安全码验证。
选择不绑定设备之后，在这里导入需要设置的 MFA，这可以用摄像头或者导入二维码文件。我用的电脑端，所以直接在应用处截图，然后导入到这里了。
点击最下面的导入，然后选择二维码 - 上传 就可以了。
导入之后是这样的，可以二次确认签发机构。
然后把生成的 6 位数字填写到 aws 控制台上，就可以成功验证了。
在 2fauth 控制台上是这样的，点开就可以查看 6 位数字验证码。
那么回到一开始的话题，怎么共享给其他账户呢？点击下方 - 管理员 - 用户 ，然后我们来新建一个普通用户。步骤基本和前面的一致。
本来以为有用户组一类的概念，把两个用户和 MFA 放在一个组里达到 share 的目的，结果发现这个分组完全是用来区分的 TAG。也没有找到把用户加到组里的操作。那就从管理员导出，再从下一个用户导入吧。
首先试了二维码，但是导入的时候就提示 server error。于是查了了 wiki，都是其他 MFA 软件导入 2fauth 的。无奈只能只能导出配置文件。名字叫做 2fauth_export.json
登录新用户的时候新建，然后选择文本文件。导入刚才的配置文件就可以了。
配置文件基本长这样：
1 | { |
整个过程有点绕，有人说每个人手机安装 google authenticator 扫一下不就好了吗？
为什么采取这个方案？
之前用手机安装类似软件，每次去三里屯维修的时候都说返厂要把数据抹掉，下次还得重新绑定，还有一些软件只认 MFA 不认人。
这过程不光折腾的够呛，而且 Apple 本身的问题还要 MFA 来买单。
起初是想做一个类似于团队共享 MFA 的场景的，类似于 RBAC，控制起来很灵活，但是实际体验下来是没有达到的。
把最早的 MFA 二维码截图 share 出去也能扫，但是不确定有效时间。
今年朋友又过来推荐，说是售后很好，可以根据自己的需求来答疑，比如把三方监控放在存在 NAS 里，比如想用私服搭建游戏服务器等等，而网上不管怎么样，还有说情绪价值一定给拉满的。
第一次咨询的时候，是和 CEO 通了个电话，抱着将新将疑的态度购买回来，拆箱，测评。相信其实很多人即使没听过王勇，也一定听过或者用过 Deepin。大学的时候使用过一段时间的 deepin，很多细节确实符合国人的使用习惯。这个背书对于技术人来说，实在是一下子路转粉。想想自己在电话里还跟对方说，其实专业的技术人员，不用和我说这么直白的词，再想想王总在 Deepin 以及 Emacs 方面的贡献， 实在是有些惭愧。
我本身是开发者，问题是技术细节相关的，比如为何这个实现和群晖类不一样，对某处设计比较反常识的地方询问和拆解，总的来说，像是上了侠客岛一样，平时自认为是开发人员里面最懂 Infra 的，结果到这里谁的 Linux 都比我玩的好。
目前重度使用了一周多，每天都会在 VIP 群里问问题。主要把维护的问题解决出来，好像附送了一个终身的云厂商支持一样。从他们的宣传来看，7 _ 18 的支持显得更加实在一些，服务相比海底捞有过之无不及。我本身用过不少 7 _ 24 小时支持的云厂商，要么低峰时候找不到人，而 24 小时支持又何尝不是对技术从业者的压榨呢？比如随时 on-call，倒班机制是我本人深恶痛绝的，有些厂家号称是 7 * 24 小时支持，但是经常已读乱回要么不回，或者干脆说这个问题和他们产品的交叉是涉及第三方，然后索性不管了。有意思的是，当使用两个公司交叉的业务时，都要让我去找对方。但是在懒猫这里就不会发生这样的问题，之前用的商店里的 dify 有问题，他们去找移植应用的人去修改了。
还有一个卖点，是硬件终身售后，甚至包括磁盘和后续的数据恢复（前提是不加密），有些推吞吐量高要求的情况甚至可以做 Raid0，然后外接 NAS 或者硬盘仓备份，所以这不是一款后端存储的产品，而是放在存储和用户之间的加速器，作为家庭的边缘算力，前面接 MBP 后面接存储池这样子。
商店目前上架了 1000+的应用，虽然官方的应用不多，但是很多三方应用都是他们的开发人员移植的，于是后来才有了越来越多的开发者也跟着移植的过程，在移植的过程中，可以学 docker-compose 的用法，以及跨架构打包 docker image ，还有单点登录的集成。这些都是我的兴趣点，而且也想学一学里面设计的机制，大学毕业的时候我想设计一款 NAS，那也仅仅是基于 centos 做了一些改动，后来买了威联通，虽然不常开案例问问题，但问的也仅仅是关于这个产品本身的东西，包括专业程度和响应级别都不是能够一概而论的。甚至连 trouble shooting 上传日志都很方便。
全容器化的服务以及对操作系统的修改，可以看出沿袭了当年在 deepin 的风骨。包括应用商店在内，很多系统组件都完全采用用容器托管。还有自己的单点登录系统，而对于 OIDC 的支持其实很多企业都没有做到。还有一点不得不提的，开发者的社区很活跃（主要指的是微信群和上架应用商店），每天都会有几位开发人员默默的上架应用和攻略。慢慢的我也熟悉了把 docker images 转换成为懒猫商店的模式。也上架了自己的几个应用，有原创的，也有把喜欢的开源项目移植过来。
最喜欢的原生应用是网盘和清单，首先说网盘曾经有一篇为什么没有人去做网盘的帖子，讲述了网盘研发成本高，就连曾经宣称用不限速的阿里云盘也变节了。改善 NAS 生态是刀山火海、暗礁遍布，却仍要做那一股清流；研发与售后成本明摆在前，却仍坚持全线自研，把服务做到极致。清单有种小清新的感觉，极简风格，日常记录一些 todo，主要同步之后多平台编辑实在很舒服。打破了关于以前产品自带的软件都很烂的固有观念。
想起来《琅琊榜》中的一句话拿来形容创始人，“如此愚蠢，却又如此有胆识的人，已经很久没见到了。”
我一直相信技术是服务生活的，但慢慢的变成了炫技以及慢慢变成了改需求以及最后变成了漫长的牛马生涯，在学生时代一直有一个远景，做一款全平台的软件自己用，后来发现学习成本巨大，而且也没有资金外包出去，虽然这几年接触了 flutter，但也没有构建一个全新的跨平台产品出来。
有了懒猫微服之后，这一切都解决了，只需要打包好 docker image，如果可以的话就上架商店给其他人用。用公网访问，TLS 证书卸载这些都一步搞定。当我们默默的喷绿联，极空间丢数据，群晖如何守旧不肯升级 CPU，以及限制磁盘认证的问题。曾经我们还忽略了这样一款从操作系统，软件生态，甚至应用商店。这款机器比我之前 DIY 构想的还要完善，完美。
我想去拆解他的技术细节。但是不想再出来一个商业竞品来扰乱这份宁静。在我看来这是一款充满着技术者热情和情怀的产品。
附送：懒猫微服社区激励机制一览
| 贡献类别 | 具体动作 | 奖励金额 | 备注条件 |
|---|---|---|---|
| 应用移植 | 成功将一款高质量的自托管应用移植并上架商店 | 100 元/款 | - 必须功能正常- 开源应用需标注上游作者- 若多人移植同一应用，仅首位上架者得奖 |
| 对接账户系统 / 网盘右键菜单 | 在移植基础上完成接口对接 | +50 元/款 | - 自己移植并对接：共 150 元/款- Fork 他人应用并补充对接：50 元/款 |
| 应用攻略编写 | 发布含截图且经验证可行的攻略，并关联商店应用 | 50 元/篇 | 鼓励分享使用经验，惠及社区 |
| 不予奖励的应用类型 | 纯网页游戏、离线 Web App、纯数据库软件等 | —— | 可自由上传，但暂无红包激励 |
]]>核心要点
- 先到先得：同款应用仅首位合规上架者获奖。
- 质量至上：功能正常、信息完整方可审核通过。
- 额外加成：完成账户系统/右键菜单对接可叠加奖励。
- 知识共享：高质量攻略同样有奖，鼓励经验传播。
懒猫网盘提供了一个开箱即用的方案，直接通过 APP 把网盘的文件夹映射自动挂载到本地，不需要像 Linux 那样 mount，也不需像 window 一样新建磁盘映射：
我们看看以前要挂载一个盘有多麻烦:
1 | # Debian/Ubuntu |
如果需要开机自动挂载，还得改/etc/fstab 里面的条目。但是，懒猫网盘可以开箱即用，不管你是用浏览器，APP，还是用访达挂载 SMB 都访问都可以。属实是解放了 Mac 党的电脑空间。
在网盘中点击自己的头像，然后设置 - 网络服务这里，可以看到设置。甚至点击起开内网服务，还会给一个 IP 地址的 SMB 地址：
smb://ip/user-name，电视盒子不能安装懒猫 app，但是有了 IP 地址之后就可以连接 SMB 了～
然后就是当贝盒子这里啦，如果你是小米盒子或者其他的盒子，只要文件管理器支持 SMB 就 OK
进入文件管理器，选择 局域网共享连接。
然后输入懒猫微服的 IP 地址，用户名密码就是微服 APP 的， 这一套有点 AD 域的感觉了。
如果你的文件管理器默认没有 SMB 也没有关系，还可以使用第三方应用进行 SMB 连接，比如这个 Github 项目，可以从 release 中下载 APK 进行安装。
连接成功后，可对文件进行扫描和管理。
通过以上配置，就可以在电视盒子上通过 SMB 连接 NAS，开心的观看的 4K 电影了。
本文是使用 Apple silicon 的 MacOS 移植到懒猫商店的踩坑记录，希望能够给大家带来帮助
Apple silicon 很好，在这年几乎带起来 ARM 的生态。但这也拉开了 ARM 和 X86 之战，用户在两大生态中穿梭，只能增加自己应用的兼容性。就比如说用来打包的 Docker image，尽管编程语言和操作系统都在底层屏蔽了硬件架构，但是容器还得用相同架构的。
这是之前移植开源项目时候忘记打包不同架构的 image 而直接推送到懒猫镜像仓库导致的问题。MacOS 默认打包了 ARMv8 架构的镜像，在 X86 上也无法运行。
1 | pg-docker run -p 5000:5500 registry.lazycat.cloud/u04123229/you/doudizhu-scorer:d1d9085174c0bf8c |
由于打包的时候容器一直在反复重启，所以在 dozzle 上也没有什么明显的报错，所以有个办法就是 ssh 进去用终端pg-docker run，这样所见即所得。dozzle 地址：https://dev.
于是重新打包，跨架构打包时候需要使用 buildx，当然前提是需要里面的运行时和代码也是跨平台的。
我们先来看概念和原理：
buildx 是 Docker 提供的一种扩展功能，它基于 BuildKit 引擎，目的是为 Docker 提供更强大的构建功能，包括：
buildx 使 Docker 能够生成多平台的镜像，这意味着你可以在一个平台上（例如 ARM 或 x86）构建适用于其他平台（如 x86_64、arm64、armv7 等）的 Docker 镜像。
docker buildx build 通过指定 --platform 参数来告诉 Docker 在构建时要生成哪些平台的镜像。例如，linux/amd64 和 linux/arm64 就分别对应 x86 和 ARM 架构。
在 buildx 构建完成后，你得到的不是一个单独的镜像，而是一个支持多平台的 manifest list，这个列表包含了不同架构的镜像。这个列表可以推送到 Docker Hub 等镜像仓库，客户端在拉取时，会根据自己的硬件架构自动选择合适的镜像。
这意味着，我们可以通过同一个镜像标签（如 your_image_name）来支持多个平台的 Docker 镜像，而用户在拉取时会自动选择适合自己平台的镜像。
--platform 参数来选择目标平台，Docker 会通过 QEMU 模拟器或者本地平台来执行构建。linux/amd64 和 linux/arm64，它会分别为这两个平台构建独立的镜像，并将它们绑定在一个 manifest list 中。--push 参数将包含多个架构镜像的 manifest list 推送到 Docker Hub 或其他镜像仓库。这个清单包含了多个平台的镜像，当用户从仓库拉取时，Docker 会自动选择与用户当前平台兼容的镜像docker buildx version 来验证/--platform linux/amd64,linux/arm64具体命令如下：
1 | docker buildx version |
在这过程中，我们可能还会使用docker tag ，这个命令可以将一个现有的镜像打上新的标签（tag），通常用于将镜像标记为自己的名字或指定版本。这对于推送镜像到 Docker Hub 或其他镜像仓库时非常有用。
1 | docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG] |
SOURCE_IMAGE[:TAG]**：要打标签的源镜像。TAG 是可选的，如果不指定，默认是 latest。TARGET_IMAGE[:TAG]**：新的目标标签，通常你可以为镜像指定一个新的名字或版本号。假设你有一个名为 my_image:latest 的镜像，并且你希望将它标记为属于你自己（例如，your_dockerhub_username/my_image:latest）：
1 | docker tag my_image:latest your_dockerhub_username/my_image:latest |
这条命令会将 my_image:latest 镜像打上 your_dockerhub_username/my_image:latest 的标签。
推送到 dockerhub 之后，然后就可以像往常一样使用 Docker 了。
1 | docker pull your_dockerhub_username/your_image_name |
如果想走 Github action 一键打包 image 的话，是这样：
1 | name: Build and Push Docker Image |
没有把 lzc-cli 写进去的原因是目前只能从终端命令行查看到推送到懒猫仓库的镜像命令，目前还不能存到一个中间位置，所以做了一个通用的版本。
事情到这里本来应该结束的，但似乎有了新的故事。
某次在打包的过程种突然报错，期间一度以为 Orbstack 出现了问题，于是卸载重装，重启电脑，均无效，GPT 和 deepseek 也只是让我检查网络连接。期间重新 docker pull 也是没问题的。
1 | characters ERROR: failed to dial qRPC: rpc error:code = Internal desc = rpc error: code = Internal desC = header key "x-docker-expoSe-session-name" contains value with non-printable ASCI #2793 |
无奈只能 Google，在 issue 里有一个评论，打包目录不能出现中文。(我的 OS 默认中文) 参考链接：https://github.com/docker/buildx/issues/2793
docker buildx build --platform linux/amd64 -t your_image_name .
1 | WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load |
这是使用 docker buildx 构建镜像时，指定了 docker-container 驱动，但是没有使用 --push 或 --load 参数。结果是，构建的镜像只会保留在构建缓存中，而不会被推送到镜像仓库或加载到本地 Docker 环境中。
我们可以通过两种方式之一来明确指定输出目标，避免出现此警告：
--push 将镜像推送到远程仓库：如果你希望构建的镜像推送到 Docker Hub 或其他 Docker 镜像仓库，可以使用 --push 参数。例如：
1 | docker buildx build --platform linux/amd64 -t your_image_name --push . |
这将把镜像推送到 Docker 仓库，而不是仅保留在本地构建缓存中。
--load 将镜像加载到本地 Docker 环境：如果你想将构建的镜像加载到本地 Docker 环境中以便后续使用（例如运行容器），可以使用 --load 参数：
1 | docker buildx build --platform linux/amd64 -t your_image_name --load . |
这会将构建的镜像加载到本地 Docker 环境，使你可以在本地运行、调试或进行其他操作。
1 | docker buildx build --platform linux/amd64,linux/arm64 -t cloudsmithy/shuangpin:latest . --load |
--load 只适用于单平台构建。如果你在跨平台构建（如 linux/amd64,linux/arm64）时使用 --load，则只会将构建的默认平台镜像加载到本地，不会加载所有平台的镜像。跨平台构建时，通常需要使用 --push 将所有平台的镜像推送到远程仓库
1 | docker buildx build --platform linux/amd64 -t cloudsmithy/shuangpin:latest . --load |
使用 --load 时，镜像会被加载到本地 Docker 守护进程中。对于大镜像，加载过程可能需要较长的时间和较多的本地存储空间。因此，如果镜像非常大，可能需要考虑是否使用 --push 直接推送到远程仓库，而不是将其加载到本地。
1 | docker buildx build --platform linux/amd64,linux/arm64 -t cloudsmithy/shuangpin:latest . --push |
对了，关于文档上提到的懒猫的 registry 不能在微服外面用，黑魔法的限制其实就是加了认证，直接返回 401.
1 | docker run -p 5000:5500 registry.lazycat.cloud/u04123229/you/doudizhu-scorer:d1d9085174c0bf8c |
希望这篇文章能够帮助大家在将开源项目移植到懒猫商店时，避免遇到一些常见的坑和问题。祝大家顺利解决跨平台构建和镜像推送中的挑战，提升开发效率！
]]>
所以应该是两套的解析结构，局域网访问的时候，就先用机器部署的私有 domain 进行解析，如果使用流量或者在外边，就是走互联网上 DNSPod 的解析记录。这个结论属于猜测，因为很多公有云也确实四这么做的，一个公开托管的 domain 用来互联网解析，一个 VPC 内的 private domain 用来解析 VPC 内部的地址。
懒猫微服和传统的 NAS 又很大的不同，如果作为小白玩家可以很快上手，当做 Sass 服务来用。但对于专业玩家，总有一种技术的强迫症，总用抽丝剥茧，从 Saas 一点点解析到 Iass，然后一点把懒猫编程能够公开访问的私有云。
比如网络。可以通过 dig 或者 nslookup 来解析
1 | dig xxx.heiyu.space +short |
但是，DNS 解析这里慢慢就出现问题了。在某次上传文件到懒猫网盘的时候，我发现速度慢的可怜，几乎是走了公网。在 VIP 答疑群里得知，流量应该是从代理转了一圈，然后回来的，所以慢，剩下的就是解决这个问题了。
那么办法就是放行白名单，不让他走代理，由于是 DNS 访问，而很多代理的规则是根据域名匹配的，所以要去改这个匹配规则。当然如果你用 nmtui 配置静态 IP 地址的话，那么内网访问也是没有问题了，直接走上级路由的默认路由表即可。
而白名单主要是放行， _.heiyu.space 和 _.lazycat.cloud 这两个域名，heiyu.space 是穿透服务，lazycat.cloud 是官网和论坛。
不同的软件有不同的设置办法，比如说用 DOMAIN-SUFFIX 来替代域名的泛解析，所以放行的时候 heiyu.space 这这样子就好。我在修改配置文件的时候用 DOMAIN-SUFFIX 匹配*.heiyu.space 不生效，花了不少的时间。实际不需要再写一次 * 号。
而最终落到配置文件上就是这样的。（之前写 DOMAIN-SUFFIX,*.lazycat.cloud,DIRECT）一直不生效。
1 | rules: |
也总结一下其他规则吧，最常见的类型有这些：
gs.apple.com → 只有访问 gs.apple.com 才会命中。apple.com → gs.apple.com、itunes.apple.com 都会命中。apple → apple.com、gs.apple.com、appleabc.xyz 都会命中。192.168.0.0/16 → 匹配 192.168 开头的所有 IP。这些是规则写法里最基本的几种，掌握了就能应对绝大多数情况。
于是想到 X86 能性能会更加好一些，比如 Android TV 这种固件，不过这种基本都是海外版本，纯净的基本什么都要自己捣鼓，而 B 站评论的第三方链接又很担心安全问题。
这问题一直持续到我购买了懒猫微服，高性能的 X86 主机，还带 HDMI（目前 Typec 不支持供电和视频传输），和飞牛的原生 Gnome 输出不同的是懒猫智慧屏其实是商店里面一个独立的 APP，本质上相当于客户端，需要手机扫码授权才能使用
登录之后是这样的，其实就是在原来 APP 的基础上加了一个 Chrome 浏览器，然后其他的应用也能在显示器上打开。右上角依次是搜索栏，软件商店和登出按钮。接下来就是可以愉快的观影了，个人体验新开一个账户，然后设置应用白名单体验会更加的好～（但是用手机遥控的时候会提示，智慧屏正在被其他用户使用是否停止 hhhh）
目前支持手机端遥控，类似市面上的盒子助手， 我连接了 Action III ，能够愉快的观影了。
由于是内置的应用，所以不存在电视盒子广告乱象的问题，11 代 I5 拿来观看 4K 也是轻松秒杀，需要什么就往网盘传什么。高端的需求只需要简单的办法。感觉不用买 Apple TV 了，如果需要其他软件比如 jellyfin 啥的也可以自己部署～。
机器有 USB 还能插键鼠，接好外设的时候记得重启一下，应该是容器部署的原因，让容器在启动的时候再读一遍/dev/bus/usb 下的设备。除了观影，接会议室的演示大屏幕也不错～
毕竟这个页面，连 debian 虚拟机都能使用，其他的应用也不在话下。想用 X86 安卓的话，直接安装到虚拟机里～
为啥说可以成为闺蜜机呢？
为啥说可以成为闺蜜机呢？
某天在商场的时候看到一个大大的带支架的还可以随时移动的平板叫做闺蜜机。
那么懒猫微服 + HDMI 投屏器/毫米波投屏器 + 可移动支架，是不是很像？
某宝上还有这样的改装套餐，解决显示器供电看来就 OK。
市面上的闺蜜机动辄大几千，配置又差强人意，还不如买懒猫微服，还有专业的售后陪玩，探索无限可能！
什么？你说闺蜜机还得有语音助手， AI 美颜，娱乐互动？快登懒猫微服用 Docker 来部署吧，还有机会上架懒猫商店哦～
]]>车载的导航是安卓，虽然已经很久没更新过了。从早些年折腾刷机的经验来看，就算不能连接 wifi，也应该是能够用 USB 转接的。尝试一圈，基本是这个情况，流量卡失效，wifi 功能被禁用掉，USB 转接有线网卡也无法识别。
于是打电话到 4S 店询问是否能够提供些许的支持，他们转到技术，然后告诉只能把车开到他们那里去看，不提供上门的支持。而作为这个年代的资深消费者，已经有千万遍劳心费力的折腾最后被售后三两句打发走的经历。 好说歹说发一张图片过去，尽管对方语气中透着些许的不耐烦。“你这个是赠送的，我们不了解情况，不是我们原厂的东西，而且很多车机是无法升级的”。于是又开始推销了自己的产品，问到是否还会遇到上述情况，还得 case by case 来看。“你这个车已经买了很多年了，早就没有保修了。”
我的需求无外服这三种：
朋友帮我查了下这个版本的卡槽，需要把整个导航拆下来，不过弄不好还耽误用倒车影像，遂放弃。
在这个论坛：http://www.allmost.org/2019/11/android-head-unit-root-device-model.html
无法联网更新，首先想到的是离线数据包，于是致电400-810-0080，这次都是机器人接听，无法转人工。
然后根据提示给了我这样的一条信息。
1 | 【高德地图】尊敬的高德用户您好，您咨询的地图数据升级问题，操作方法：请您点击链接 https://auto.amap.com/download/map_data#public ，选择对应版本下载即可；同时您可在下载界面点击我不会安装查看说明， 感谢您对高德的关注与支持！ |
在年初的时候还针对 Mac 端的高德地图无法更新的问题咨询客服，却被告知没有这样的产品进而“建议”使用网页版。，而我一直是在 App Store 下载的。当时几乎想到距离我两三公里的高德总部去要个说法，而这次的离线数据包更是提示升级中，无法下载。
于是退而求其次，我下载一个最新的机车版是不是会更好一些？安装之前还担心数据丢失问题，于是看到下面这个话就“放心”了。
但是安装之后，之前的离线地图全部消失，甚至很”贴心“的把之前旧数据的磁盘空间都释放了出来。原来马上爆满的磁盘空间，突然瘦身了。但，实时导航，手机同步，问题反馈都共用报错无法联网，这次而且无法回滚。不能上网的车机，不能联网的地图，被清空的旧版数据。第二次想杀到高德总部。
大学同学在嵌入式行业，经验比我丰富些，于是去求助。他告诉我可以尝试通过 ADB 进入调试系统，然后使用命令行拉起来 wifi 的进程 ，看看是否能够改善。
分析之后查看到，车机的版本是 Android6.0，基于 Linux3.18 的内核，连包管理工具也没有，甚至连 top 都会把上位机卡死。于是开始分析思路，能够开启热点说明有 wifi 模块，然后依次排查进程是否启动，驱动是否安装，内核在启动时是否正常加载该驱动。那一刹那，感觉自己从调侃的修电脑，修家电，修水电，最后到了修车侠。
还好支持开发者模式，adb 调试的时候使用了甲壳虫助手，比用 USB 连接安卓 ADB 方便的多，把软件安装在车机上，不用再像以前刷机一样一遍又一遍的执行 adb device -l 查找设备，虽然这个机器慢一点，但是总归还是能够很稳的连接 ABD，然后一遍一遍尝试命令，Google，GPT，Deepseek，一遍又一遍。
机车给了一个 USB 的接口，刚好拿来外接键盘，把 MBP 搬到车里查资料，手机开了热点越来越烫，然后就是一遍的调试，而 MBP 不能通过 adb 扫描到机车，不确定是不是和工厂模式里的设置有关系。这过程有点像刷机，有一点想像服务器上调 Linux。在此之前也想过用 USB 转 J45 连接路由器，就算没有网络的情况下，也应该能够显示一张没有网络连接的以太网卡。试验之后是完美没有，和朋友讨论之后，猜想是和内核驱动在编译的时候没有打包通用驱动或者这张卡驱动导致的。（来自之前 UFS 安装 Linux 的经验）而这个机器上完全无法执行 lsmod 和和 cat /proc/modules，而**dmesg | grep -i "load"**的记录也是空，实在无法想象这个系统是如何加载底层驱动的。
最后思来想去大概是这几个命令生效了，因为后来重启才发现 wifi 模块加载出来了，中间加执行了很多。
1 | # 在甲壳虫中可以省略adb shell字眼 |
回去看到 GPT 的提示，说操作完一定重启，否则配置不会写入 NVRAM。（我之前忽略了这个，走了很多弯路）
我的dumpsys wifi 里出现的那一行长这样，
1 | Wi‑Fi is disabled |
它只说明 系统目前把 Wi‑Fi 开关拨到了“关”，并不直接告诉你“有没有 Wi‑Fi 硬件”。要分清楚是“硬件存在但关掉”还是“根本没有硬件/驱动”，可以再看 4 处信号：
| 检查点 | 如何查看 | 典型输出 | 结论 |
| ——————- | ————————————– | ———————– | —————————————————- | ———————————————- | — |
| 1. Service 列表 | adb shell service list | grep -i wifi | wifi: [android.net.wifi.IWifiManager] | 看到这一行 → Framework 里 有 Wi‑Fi 服务 |
| 2. 驱动状态 | adb shell getprop wlan.driver.status | ok / ready / unloaded | 有值 → 内核认识 Wi‑Fi 芯片；空值 → 多半缺驱动/被裁掉 |
| 3. 网络接口 | adb shell ifconfig -a | grep wlan | wlan0 ... | 能看到 wlan0 → 芯片已初始化；完全没有 → 未加载 |
| 4. 内核模块 | adb shell lsmod \| grep -E "8188 | rt5370 | wlan" | | |
| 情况 | 解释 | 解决办法 |
|---|---|---|
| Service 有，wlan0 有，driver=ok，但 dumpsys 显示 disabled | 硬件存在，只是软件开关关掉 | 用 UI 开关或adb shell settings put global wifi_on 1再重启 Wi‑Fi |
| Service 有，但 wlan0/驱动都没有 | Framework 在，但 内核缺驱动/Factory 里关闭了 Wi‑Fi | 先在工厂设置里勾选 WIFI 并保存；如仍无驱动 → 刷带 wifi_bt 的 ROM 或插 USB 网卡 |
| Service 没有（grep 不到 wifi） | ROM/MCU 层完全裁掉了 Wi‑Fi | 只能刷完整固件或硬改/外接网卡 |
| Service 有，driver=unloaded | 驱动文件在，但未成功加载 | Factory 里未启用 / 模块版本不匹配 → 勾选保存或换匹配的系统+MCU |
svc 的情况下）1 | adb shell settings put global wifi_on 1 |
如果改完仍显示 disabled，就说明硬件/驱动层面还没点亮，需要回“工厂设置”勾选 Wi‑Fi 或换带驱动的固件。
一句话：dumpsys wifi 看到 disabled 只是“当前关着”，并不代表“没有 Wi‑Fi”。再看服务列表、驱动状态、wlan0 接口等就能分辨：
我的结果是。无法执行 lsmod，服务正常，驱动正常，而网络接口必须在启动共享热点的时候才能看到，最后在工厂模式的时候手滑点了重启才发现一切正常。
看到这个页面的时候就感觉一切的付出都值得了，所谓念念不忘，必有回想吧。（设置里还是没有 wifi 选项，还得自己从下拉菜单启动）
主要用来开关一些功能，实际在我这个过程中好像没有起到太大的作用，这个主要针对整个 OS 而言，有些版本可能在这里启动 wifi，但是我这个没有，主要还是见识一下车机模式，图一乐。
这些是 GPT 给的，没有真正执行：
ADB 直接拉起
1 | bash |
若提示 Error type 3 仍找不到，说明 ROM 确实删掉了对应 Activity。
家里在高层，即使把车开到楼下也不见能够有多好的信号，也能是根本就搜不到。然后突发奇想，正好之前有一个
交流的移动电源，然后把 Mesh 子路由拿到楼下供电，然后把楼上的路由放在窗户上。这才是有线 Mesh 的正确用法，尽管在高层，还能跑到 10M 以上的速度，然后再用楼下的子路由无线桥接，可以媲美一些无线路由器的速度了。
其实还有一个方案，借助 POE 路由的便携性，把网线从窗户顺下去，然后顺便也解决供电的问题。但是，翻了翻箱子，确实没有这么长的网线，那么就速战速决，将就一下把。
设备如下，方案做好了，摸黑也要实施完。
一些安卓 8 以上才可以用的命令，先记录下来，作为折腾的过程。
1 | iwlist wlan0 scan |
下面给你 4 种常用办法，按「年代新 → 旧」排列，只要你的 ROM 里有对应的命令或工具，就能在 PC 端终端 直接看到扫描结果。不用担心全记不住，逐个试，命令不认识就跳下一个。
| 方法 | 适用 Android 版本 | 是否要 root | 命令示例 |
|---|---|---|---|
A. cmd wifi 子命令 | 8.1 (Oreo) 及以上，只要系统内置 cmd | ❌ | bash\nadb shell cmd wifi enable # 先确保开 Wi‑Fi\nadb shell cmd wifi scan # 立即触发一次扫描\nadb shell cmd wifi list-scan-results # 打印扫描结果（BSSID/SSID/信号）\n |
B. dumpsys wifi 解析 | 4.0+（几乎所有） | ❌ | ```bash\nadb shell dumpsys wifi |
C. wpa_cli 工具链 | ROM 里带 wpa_supplicant + wpa_cli | ⭕（通常要 root） | bash\nadb shell su -c 'wpa_cli scan'\nadb shell su -c 'wpa_cli scan_results'\n |
D. iw/iwlist 直查射频 | 内核自带 mac80211/CFG80211，工具在 /system/xbin | ⭕ | ```bash\nadb shell su -c ‘iw dev wlan0 scan |
让 ADB 连上车机
1 | adb devices # 出现 device 才算连上 |
确保 Wi‑Fi 已经启用
adb shell cmd wifi enable 或 settings put global wifi_on 1 后再开一次 UI 开关。adb shell dumpsys wifi | grep "Wi‑Fi is" → enabled/disabled。触发一次扫描
新版用 cmd wifi scan；旧版可发送广播：
1 | adb shell am broadcast -a android.intent.action.SCAN_RESULTS |
查看结果
<hidden>：说明热点隐藏了 SSID，属正常现象。cmd wifi list-scan-results）1 | BSSID frequency level SSID |
字段含义：
| 字段 | 解释 |
|---|---|
| BSSID | 无线 AP 的 MAC 地址 |
| frequency | 2412 – 2472 MHz = 2.4 GHz；5180 + = 5 GHz |
| level | 信号强度，单位 dBm（-30≈ 满格，-80≈ 临界） |
| SSID | 热点名称（隐藏网络会显示 <hidden>） |
| 症状 | 原因 | 解决 |
|---|---|---|
cmd: not found | ROM 删了 toybox / cmd | 改用 方法 B、C、D |
cmd wifi: Unknown command | Android 7.1 及以下 | 用 dumpsys 或 wpa_cli |
permission denied / su: not found | 没 root | 选不用 root 的 方法 A 或 B |
| 扫描结果为空 | Wi‑Fi 实际没启用、没有天线、驱动缺失 | 先 settings put global wifi_on 1 并从 UI 打开；或检查硬件/ROM |
批量重扫：想每 5 秒自动扫一次可用循环：
1 | while true; do adb shell cmd wifi scan; adb shell cmd wifi list-scan-results | head -n 10; sleep 5; done |
只取最强信号：
1 | adb shell cmd wifi list-scan-results | sed 1d | sort -k3 -n | head |
无 Wi‑Fi 硬件时：任何扫描命令都会报错或空结果 —— 确认已在 Factory Setting 勾选 Wi‑Fi、或插上 RTL8188EU/RT5370 USB 网卡后重试。
一句话：连好 ADB → 开 Wi‑Fi → 在 PC 端执行 **
cmd wifi scan && cmd wifi list-scan-results**（Android 8.1+ 最方便）；旧版系统就用adb shell dumpsys wifi或 root 下的wpa_cli scan_results/iw dev wlan0 scan来列出热点。祝你早日看到满屏 SSID！
dumpsys 是 只读（dump） 的诊断工具——它只能把系统当前状态“倒”出来给你看，完全没有写入/控制能力。
所以：
dumpsys wifi只能查看 Wi‑Fi 的开关状态、扫描结果、连接信息等，不能直接把开关从 OFF 变成 ON。
dumpsys 不能改状态？dumpsys 调用各系统服务的 dump() 接口，这个接口按约定必须是“无副作用”的纯输出。dumpsys root 权限，它也只有 READ 能力。任选其一，具体支持情况取决于你的 ROM / 是否 root
| 方法 | 是否 root | Android 版本 | 示例 |
|---|---|---|---|
| settings put global wifi_on 1 | 不要求 | 4.0+ | adb shell settings put global wifi_on 1 |
| service call wifi 13 i32 1 | 需要 | 4.1+ | adb shell su -c 'service call wifi 13 i32 1' |
| cmd wifi enable | 不要求 | 8.1+ | adb shell cmd wifi enable |
| 广播／Intent(部分 ROM 有效) | 不要求 | 4.0+ | adb shell am start -a android.settings.WIFI_SETTINGS（拉起设置页后系统会自动打开） |
svc wifi enable也是写操作，但你的 ROM 把svc精简掉了，所以用不了。
1 | # 1. 打开 Wi‑Fi（写 settings） |
大多数 MT3561 Android 6/7 车机用这两行就能把 Wi‑Fi 开关拨到 ON。
如果执行后 dumpsys wifi 仍显示 disabled，说明：
dumpsys wifi 只能看，不能改。settings put …、service call wifi …、cmd wifi enable（≥8.1）等写操作；提前确保 ROM 没把 Wi‑Fi 功能裁掉，或已在“工厂设置”里启用。祝你折腾顺利！dumpsys wifi 里出现的那一行通常长这样：
1 | Wi‑Fi is disabled |
它只说明 系统目前把 Wi‑Fi 开关拨到了“关”，并不直接告诉你“有没有 Wi‑Fi 硬件”。要分清楚是“硬件存在但关掉”还是“根本没有硬件/驱动”，可以再看 4 处信号：
| 检查点 | 如何查看 | 典型输出 | 结论 |
| ——————- | ————————————– | ———————– | —————————————————- | ———————————————- | — |
| 1. Service 列表 | adb shell service list | grep -i wifi | wifi: [android.net.wifi.IWifiManager] | 看到这一行 → Framework 里 有 Wi‑Fi 服务 |
| 2. 驱动状态 | adb shell getprop wlan.driver.status | ok / ready / unloaded | 有值 → 内核认识 Wi‑Fi 芯片；空值 → 多半缺驱动/被裁掉 |
| 3. 网络接口 | adb shell ifconfig -a | grep wlan | wlan0 ... | 能看到 wlan0 → 芯片已初始化；完全没有 → 未加载 |
| 4. 内核模块 | adb shell lsmod \| grep -E "8188 | rt5370 | wlan" | | |
| 情况 | 解释 | 解决办法 |
|---|---|---|
| Service 有，wlan0 有，driver=ok，但 dumpsys 显示 disabled | 硬件存在，只是软件开关关掉 | 用 UI 开关或adb shell settings put global wifi_on 1再重启 Wi‑Fi |
| Service 有，但 wlan0/驱动都没有 | Framework 在，但 内核缺驱动/Factory 里关闭了 Wi‑Fi | 先在工厂设置里勾选 WIFI 并保存；如仍无驱动 → 刷带 wifi_bt 的 ROM 或插 USB 网卡 |
| Service 没有（grep 不到 wifi） | ROM/MCU 层完全裁掉了 Wi‑Fi | 只能刷完整固件或硬改/外接网卡 |
| Service 有，driver=unloaded | 驱动文件在，但未成功加载 | Factory 里未启用 / 模块版本不匹配 → 勾选保存或换匹配的系统+MCU |
svc 的情况下）1 | adb shell settings put global wifi_on 1 |
如果改完仍显示 disabled，就说明硬件/驱动层面还没点亮，需要回“工厂设置”勾选 Wi‑Fi 或换带驱动的固件。
一句话：dumpsys wifi 看到 disabled 只是“当前关着”，并不代表“没有 Wi‑Fi”。再看服务列表、驱动状态、wlan0 接口等就能分辨：
下面所有命令都在 PC 端终端 输入（前面带
adb），车机端只需提前打开「USB 调试」。
| 功能 | Android 6.0 支持情况 | 备注 |
|---|---|---|
| cmd wifi … | ❌ 没有（8.1 才加入） | |
| svc wifi enable/disable | ✅ 系统自带 toybox svc但你的 ROM 把 svc 删掉，才会显示 not found | |
| settings put global wifi_on | ✅ 无 root 也能写 | |
| service call wifi … | ✅ 需要 root/SU | |
| wpa_cli / iwlist / iw | 取决于 ROM 是否编译进 /system/xbin |
svc 情况下打开 Wi‑Fi（不需要 root）1 | # 打开 Wi‑Fi |
1 | adb shell settings get global wifi_on # 应返回 1 |
如果还是 _disabled_，说明 Factory Setting 里仍把 Wi‑Fi 禁掉 或 驱动没加载——请回工厂菜单勾选 WIFI 或插免驱 USB 网卡后再试。
1 | # 查询 wifi 服务是否存在 |
| 方法 | 是否 root | 命令 |
|---|---|---|
| settings + dumplog（最稳） | ❌ | ```bash\nadb shell dumpsys wifi |
| wpa_cli（ROM 带 wpa_supplicant） | ⭕ | bash\nadb shell su -c 'wpa_cli scan'\nadb shell su -c 'wpa_cli scan_results'\n |
| iwlist（busybox） | ⭕ | ```bash\nadb shell su -c ‘busybox iwlist wlan0 scanning |
1 | adb shell lsmod | grep -E "8188|rt5370|wlan" |
| 结果 | 说明 | 后续 |
|---|---|---|
| 能看到 8188eu / rt5370sta 等模块 | 驱动已插 | 只需把 Wi‑Fi 开关打开即可 |
| 没有任何模块 / getprop 为空 | 内核缺驱动 or Factory 关闭 | 1) Factory 勾选 WIFI 保存 2) 刷带 wifi_bt 的 ROM3) 外接免驱 USB 网卡 |
在 Android 6.0 + Linux 3.x 的 evb3561sv 车机里：
svc 被删时，用 settings put global wifi_on 1 + 状态广播 就能无界面开 Wi‑Fi；service call wifi 13 i32 1 直接写 Binder；dumpsys wifi 看到 disabled 只是开关关着，不代表硬件不存在——再看 service list、lsmod、wlan0 就能判断；shell: svc wifi enable 这条命令只是 Android 自带的小工具封装；
你那台 evb3561sv 的 ROM 把 toybox/toolbox 精简了，直接把 svc 可执行文件删掉，所以才提示 _not found_。
没关系，核心功能还在——我们可以绕过 svc，改用 系统设置 / Binder 服务 / cmd 三种办法来“硬切” Wi‑Fi。先按难度从低到高排一下，你照顺序尝试即可。
| 检查 | 命令 (PC 端执行) | 说明 |
|---|---|---|
| 车机是否连上 ADB | adb devices | 看到 device 才算连通；若是 unauthorized，去车机点“始终允许”。 |
ROM 里有没有 cmd/settings/service | adb shell which cmd; which settings; which service | 至少会有 settings 和 **service**；有哪个就用哪个。 |
1 | # 开启 Wi‑Fi |
验证：
adb shell settings get global wifi_on→ 返回1；adb shell dumpsys wifi | grep "Wi-Fi is"→ 出现 enabled。
如果重启车机后又变回 0，说明 ROM 在启动脚本里把 Wi‑Fi 强行关掉——请继续看下一招。
先确认系统里有 wifi 服务：
1 | adb shell service list | grep -i wifi |
调用 setWifiEnabled(true)（在 Android 5/6 上通常是 事务码 13；如果无效换 6、8 试）：
1 | adb shell su -c 'service call wifi 13 i32 1' # 开 |
1 | adb shell cmd wifi enable |
在 MT3561 Android 8.1（Oreo）第三方 ROM 上测试可行；如果返回 Unknown command 就说明版本还在 7.1 以下，没有
cmd wifi子命令。
再回 Factory Setting
查驱动
1 | adb shell lsmod | grep -E '8188|rt5370|wlan' |
解决思路
| 路线 | 说明 |
|---|---|
| 刷带 wifi_bt 字样的 完整 ROM + MCU | 与主板编码 evb3561sv_w_65_m0 对应的版本，一键恢复 Wi‑Fi。 |
| 外接 RTL8188EU / RT5370 USB 网卡 | 车机对这两款芯片免驱，插上后重启即可在「网络与互联网」里出现 Wi‑Fi。 |
| 临时上网 | 手机 USB 共享网络 (Tethering) → 车机当“有线客户端”，不依赖 Wi‑Fi 射频。 |
| 报错 / 现象 | 判断 | 处理 |
|---|---|---|
svc: not found | ROM 精简掉 toybox → 用 settings / service 方案 | 见步骤 1/2 |
settings: not found | 工具也被删 | 装一个 busybox 或 toybox APK，或直接跳到 service call wifi |
service call wifi … result=0x0 且 Wi‑Fi 仍 off | Binder 调用了，但返回 false | 多半 “Factory” 里没勾选 Wi‑Fi 或硬件缺失 |
service list 根本没 wifi | 内核 / Framework 把整个 Wi‑Fi Manager 移除了 | 只能刷新 ROM 或外接 USB 网卡 |
你的 ROM 砍掉了
svc可执行文件，所以svc wifi enable无法用；先尝试 **settings put global wifi_on 1**，再不行就（有 root 时）用 **service call wifi 13 i32 1**。若系统连wifi服务都不存在，就说明 Wi‑Fi 在 Factory Setting 被禁用或 ROM/硬件干脆没装，最终只能刷含驱动的完整固件或外接免驱 USB 网卡。祝折腾顺利！
下面给你一份最通用、从零到一的操作清单，帮你重新进入 evb3561sv 车机的「工厂设置（Factory Setting）」隐藏菜单，并把 Wi‑Fi 模块启/停用。整套流程 3‑5 分钟，风险低，只要别在保存‑重启时断电即可。
| 步骤 | 详细做法 | 补充说明 |
|---|---|---|
| 1 回到主界面 | 点实体 🏠 键或手势返回，退出你现在的「运行命令」App，回到桌面。 | |
| 2 打开系统设置 | 桌面找灰色齿轮 → 设置（Settings/设置中心/Car Setting）。如果桌面上没有，可在所有 App 列表里找“设置”或“车机设置”。 | |
| 3 定位“工厂设置”入口 | 不同 ROM 位置略有差异，常见三种：① 系统 → 关于设备 → 工厂设置② Car Setting → 版本信息 页面右上角小齿轮/🔧③ 直接在主设置页底部看到 Factory/“工厂” 按钮 | 还有少数机型需要在顶部状态栏下拉，长按 ⚙️ 5 秒弹出“工厂模式”，可先试前两种常见路径再换招。 |
| 4 输入密码 | 出现数字键盘后依次试：• 8888（XY‑Auto 机型）• 3368（FYT 机型，多数 evb3561sv 属此族）• 3711、0000、123456 等备选 | 正确密码会立刻进入隐藏菜单；错了则原样返回，继续换密码即可。(XDA Forums, FCC Report) |
| 5 勾选/取消 Wi‑Fi | 进入后通常会看到 General / Feature / Hardware 等标签：• 找到 WIFI / WLAN / WIFI&BT 这一项• 启用 → 打勾；停用 → 取消勾选• 若有 BT 选项，可一并视需要勾选 | 字段名可能稍有区别，但一定带 “WIFI” 字样；看不到这一行多半是刷错 MCU 或 ROM 被阉割。 |
| 6 保存并重启 | 点页面底部 Save / Apply / OK；系统提示 Reboot now? 选 Yes，或手动重启一次电源。 | 期间千万别断 12 V 电源（ACC + B+)。 |
| 7 验证生效 | 重启后进 设置 → 网络与互联网：• 若出现 Wi‑Fi 开关并能扫描热点，说明启用成功；• 若仍无开关，则回隐藏菜单检查是否勾选保存成功，或确认硬件/驱动。 | 想进一步排错：adb shell getprop wlan.driver.status 应返回 ok/ready；空值说明驱动仍未加载。 |
用 Activity Launcher 类工具
factory / settings.FactorySetting / com.twd.factorysetting，点进去也能弹出隐藏菜单。ADB 直接拉起
1 | adb shell am start -n com.twd.settings/.FactorySetting # FYT/TS10 系常见 |
若提示 Error type 3 仍找不到，说明 ROM 确实删掉了对应 Activity。
| 疑问 | 解答 |
|---|---|
| 密码都试完仍进不去？ | 可能设备品牌归属不同，联系卖家确认密码；或在 Activity Launcher 搜索 factory 直接拉 Activity。 |
| 选项勾了保存却自动跳回未勾？ | MCU 与系统包不匹配 → 刷与主板版本一致、带 wifi_bt 标识的完整 ROM + MCU。 |
| Wi‑Fi 列表能扫，但想让车机开热点？ | 默认无线芯片可能只支持 STA；需外接支持 AP 模式的 USB Wi‑Fi (RTL8188EU/RT5370) 或刷支持 hostapd 的内核。 |
]]>一句话：回桌面 → 打开「设置」→ 找到「工厂设置」→ 输入 8888／3368 等密码 → 在隐藏菜单勾选 WIFI → 保存并重启；若连入口都找不到，就用 Activity Launcher 或 ADB 命令直拉工厂设置界面，再按同样步骤操作。祝你成功点亮 Wi‑Fi！
我选择使用 Ventoy 进行引导，这样可以避免反复使用 Etcher 等工具进行写盘操作。
启动安装程序
启动后，您将看到如下界面：
用户协议
阅读并接受用户协议：
选择安装目录
选择安装 Proxmox VE 的磁盘：
设置密码
设置 root 用户的密码，邮箱地址可以随意填写：
配置网络
设置系统的 IP 地址：
开始安装
确认所有设置后，开始安装：
安装完成
安装完成后，系统将提示您访问 Web 管理界面，默认端口为 8006：
重启系统
拔掉引导 U 盘并重启系统：
登录系统
使用前面设置的密码登录系统：
Web 管理界面
登录后，您将看到 Proxmox VE 的 Web 管理界面：
测试网络连通性
确保网络连接正常：
上传 ISO 文件
首先，上传操作系统的 ISO 文件：
创建虚拟机
设置虚拟机编号
为虚拟机设置一个编号：
选择镜像
选择之前上传的 ISO 文件作为安装镜像：
配置硬件
主板信息
保持默认设置即可：
磁盘设置
建议选择 VirtIO 以提高性能：
CPU 配置
注意不要超过宿主机的 CPU 核心数，否则虚拟机将无法启动：
内存分配
根据需求分配内存：
网络设置
同样建议选择 VirtIO：
确认信息
确认所有设置无误后，点击完成：
启动虚拟机
启动虚拟机并开始安装操作系统：
安装过程
按照提示进行操作系统安装：
加载驱动
在安装过程中，加载 VirtIO 驱动：
分区与安装
对磁盘进行分区并开始安装：
复制安装文件
安装程序将复制文件并进行系统安装：
设置系统时区：
安装完成后，系统可能暂时无法联网，稍后我们将安装网络驱动：
为操作系统设置用户名和密码：
安装 VirtIO 网络驱动以确保网络功能正常：
对于 Linux 系统，安装过程类似，但通常 Linux 系统已经自带 VirtIO 驱动，无需手动安装：
通过以上步骤，您应该已经成功在 Proxmox VE 中安装并配置了虚拟机。希望本指南对您有所帮助！
]]>下面就以实际操作为例，教大家新建用户，并且了解这些自带的安全机制。
设置 - 用户管理，这里可以看到现存的账户，第一次激活的时候会提示注册一个管理员账户，后面可以右上角点击邀请成员，然后会得到弹出一个二维码，新的客户端需要下载懒猫客户端，然后客户端扫码添加输入信息即可。
扫码后可以为新用户设置用户名和密码。客户端下载地址：
👉 https://lazycat.cloud/download
注册完成后，新成员就可以使用自己的账号登录懒猫微服啦。默认是“非管理员权限”，更安全。
新建之后，我对这个新用户的画像是用户而不是管理者，所以只需要登录之后看到应用白名单就可以了。
点击新建用户的头像，可以设置用户可以看见应用的白名单。
比如，我只授权了家庭成员使用懒猫网盘、懒猫清单等基础工具。于是使用手机端登录新的账户，可以看到在我的应用中只有刚刚选中那些，这对于日常使用来说刚刚好，这个页面相对于安装了几十个 app 的管理页面来说，实在是清爽。
在此之前我们先来介绍多因子验证（MFA），通俗来讲我们在使用用户名密码登录的时候有时候还要接收一个验证码，有时候是发到邮箱的，有的是手机短信，还有个需要安装特定的 APP 来查看，比如 Authy，Google Authenticator。
而懒猫微服在 APP 中内置了 MFA 接收验证码的功能，新设备登录的时候会有如下提示：
在一台新的设备登录懒猫账户的时候，已经登录这个账户的设备就会弹出这个提示，这个时候我一般是提前打开懒猫微服 APP。
当然如果没有提前打开或者登录呢，也可以在「微服管理 - 安全码」来查看，比如这样，这个方式很 Apple 但是用着比 Apple 的提示舒服多了。
那么什么时候才会触发这个 MFA 呢？经过不完全测试，主要还是在这里设备管理这里有一个云端白名单，在这里的设备可以就可以免去 MFA 的验证，如果删除某个设备之后，这个设备会马上注销登录，并且在此登录的时候还需要 MFA 验证。这个操作，极大了降低了被黑客攻击的可能性。
当然如果你觉得 MFA 比较麻烦，那么也可以使用手机号码的方式进行登录，绑定手机号，然后用收验证码的方式进行登录,比如这样：
1 | 【懒猫微服】验证码：0000，5分钟内有效！请勿转发或泄漏。 |
以前用过很多 NAS，一直苦于怕黑客攻击而没有监管 NAS 放在互联网，而一套完整的登录机制也要花费很大的精力去维护，拓展。期间也选择过蒲公英这样的异地组网设备，虽然可以达到目的，但是过程不尽如人意，对于很多国产生态来说，售后一直是缺失的很重要的一环。而懒猫微服恰好弥补了这样的短板，让懂技术的人从繁杂的维护设备中解放出来，像使用公有云一样的使用 NAS。
如果你用过 Elasticsearch，那就一定知道 Kibana。Infinilabs Console，就是极限科技团队开发的国产可视化控制台，是一个面向 Easysearch、Elasticsearch 和 OpenSearch 的运维、监控、数据管理平台，可以看作是国产版的 Kibana 替代品。
最初接触这个款产品的时候让我眼前一亮，它能够借助 Easysearch 或者 Elasticsearch 的 REST API 来连接集群，同时也高效地管理和监控 Elasticsearch、OpenSearch 以及 INFINI Easysearch 等搜索引擎集群，提供统一的运维、监控、安全和数据管理能力。这一点其实是 Kibana 比不了的，尽管是老牌软件，但是初学 ES 的时候 Kibana 连接 ES 要查 log 设置一些 key，这个整个部署过程就花了一个小上午的时间。而且跨版本，跨引擎来支持的能力也是其他可视化工具无法比拟的。简单来说，真的很符合国人的使用习惯。
首先我们可以在连接的时候不同的引擎（Easysearch、Elasticsearch、OpenSearch ），以及你集群的位置（线下还是在各种云上），同时支持 HTTP 和 HTTPS 的连接。
连接之后，可以看到已经正确识别出来了的 Easysearch、Elasticsearch 和 OpenSearch，并且抓取了相应的数据监控，比如基本的集群状态，节点数量，索引，分片以及文档的数量，还有磁盘和 JVM 的占用。
执行 DSL 的时候可以开启多个 TAB 页这个是我最喜欢的功能，尤其在做集群迁移的时候再也不用找不同的系统去登录了，这里手动@aws 的 OpenSearch。除此之外，做快照传到 S3 的时候也不用担心 access_key 读不到的问题了。曾经我是托管 OpenSearch 的用户，托管节点有诸多问题，无法登录，由于服务本身的问题导致业务滞后（升级卡住，看门狗不定时杀进程），做快照必须借助 Postman 来传递 IAM 凭证。但，换了 Infinilabs console 和 Easysearch 之后，整个世界都清净了。
GitHub 项目地址如下：https://github.com/infinilabs/console
懒猫微服解决了我日常使用 NAS 的几个痛点：
docker ps 一把梭；部署成功后会给到一个域名，然后通过域名访问可以自动解析内外网的 IP 地址，同时也自带了路由守卫功能来重定向到懒猫的 SSO，
而在传统 NAS 部署 Authentik 然后再去应用端做 SSO 的适配应该是 NAS 玩家的终极梦想，而上架商店之后自动集成了这样的认证系统（也是单点登录）。然后，在外边的时候也可以监控和操作自己的 ES 集群啦～（随地大小班的理由又多了一条）
因为上架的应用是 HTTP 的，懒猫微服还能自动做了一个 TLS 传输，用的他们自己域名，然后通过 https 访问 Infinilabs Console。
除此之外还自带了 dozzle，可以很方便查看安装应用的上架信息，毕竟对于开发者来说，装机玩 NAS 是兴趣，但是搭建好之后的维护问题也同样劳心费力，真的一点都不想浪费时间和精力，那么杂活就交给平台来管理吧。
进入懒猫微服的【应用商店】，搜索：infinilabs.console一键安装并启动，打开浏览器，开始使用 Infinilabs Console 吧～
地址如下：
https://lazycat.cloud/appstore/#/shop/detail/xu.infinilabs.console
官方文档如下：
https://developer.lazycat.cloud/ssh.html
安装懒猫开发者工具，然后再右上角能够看到 sshd 服务的状态。
然后点击开启，之后我们才可以使用 ssh 登录，在写这篇文章测试的时候，我关闭了这个按钮，再去 ssh 直接就报错了。
默认是 root 身份登录，密码在开发者工具里启动的时候设置：
1 | ssh root@<your-service-name>.heiyu.space |
如果觉得密码麻烦，也可以导入密钥，更加安全：
1 | ssh-copy-id -i ~/.ssh/id_ed25519 root@xxxxx.heiyu.space |
输出如下：
1 | /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/xu/.ssh/id_ed25519.pub" |
如果觉得 root 用户不安全的话，可以新建一个日常用户，然后加到 docker 组里面，也能正常使用 docker
1 | sudo useradd -m -s /bin/bash user1 |
如果遇到到 root 组会有无法使用 sudo 的问题，请独立安装，sudo 是单独的软件包,需要安装才有.并不是所有 Linux 都有 sudo
1 | apt update && apt install sudo |
注意：要开着懒猫微服 APP ，否则无法使用 heiyu.space 提供的穿透服务。
下面就手把手教大家几种实用的方法。
在 Mac 上，我们有更高级的玩法。
不少现代网站都支持 PWA（Progressive Web App），简单来说，就是让网页像 App 一样运行：
下面是懒猫清单的安装效果：
支持 PWA 的网站，在地址栏右侧会自动弹出“安装应用”按钮。
只需点击它，就能轻松将网页保存为应用。
PWA 的优点：速度快、体验好、支持离线，真正做到了网页与 App 的无缝结合。
通过 PWA 添加之后，会在 Finder 里弹出 Chrome 应用，我这里添加了懒猫网盘，懒猫原生的 APP 基本都是带 PWA 的，所以这一点体验很好。
添加完桌面应用之后，浏览器会有“在应用中打开”的提示，点击就可以像 APP 一下打开，就是前面第二张懒猫清单的图片。
安装时你可以自定义应用名称，这里以 OnlyOffice 为例。
这样做还可以解决 Mac 没有 Office 订阅的痛点，直接通过网页版弥补。
完成后，应用会存放在：
1 | /Users/你的用户名/Applications/Chrome Apps.localized/ |
它们会以.app格式存在，完全就像普通 Mac 应用一样。
1 | ❰~/Applications/Chrome Apps.localized❱✔≻ ls |
对于不支持 PWA 的网站，Safari 也提供了一个类似的解决方案。
输入自定义的应用名称，点击“添加”。这个应用会自动放在应用程序里面。
应用将会被保存到“应用程序”文件夹中，支持从程序坞、启动台或 Spotlight 快速启动。
无论是通过 Chrome 还是 Safari 安装的网页 App，安装完成后都可以像普通应用一样拖到 Dock。
只需保持懒猫微服务后台连接，点击 Dock 图标，就能立即打开应用，体验和原生 App 无异！
当然，你也可以用 Python 快速实现一个简单的网页启动器：
1 | import webbrowser |
支持新窗口、新标签等操作，适合简单自定义。
通过以上方法，我们就可以把常用的懒猫 APP 变成 Mac 的桌面应用，随时一键直达，告别繁琐的搜索过程，体验飞跃式提升！
注意：AWS DMS 原生仅支持托管的 OpenSearch 和 Elasticsearch，不直接支持 EasySearch。本文将介绍如何通过一些配置技巧，优雅地解决这个问题。
首先，我们需要准备好待迁移的 MySQL 数据库。我这里使用的是DBeaver工具，当然你也可以选择更专业的 MySQL Workbench 或 DataGrip。
新建数据库时，选择utf8mb4编码，库名命名为source（后续 DMS 迁移任务中会用到）。
接下来创建数据表并定义字段。图形化工具可以避免手写 DDL，对非 DBA 用户非常友好。
为了验证迁移效果，我们先写几条假数据。
确认数据已成功写入并提交。
在 AWS DMS 中，首先需要定义源端点。MySQL 作为数据源，EasySearch 作为目标端。
我的 EasySearch 部署在公网的 Linux 服务器上。配置目标端点时，有两个重点：
只需要调整这两个关键参数，即可完成兼容。
迁移任务需要一个复制实例，即 DMS 后台自动启动的迁移代理服务器。
实例启动后，记得测试源端（MySQL）和目标端（EasySearch）的连通性，确保网络正常。
在控制台新建迁移任务
为了支持 CDC（持续复制），需要提前在 MySQL 开启 binlog，并调整格式为ROW。
在 DMS 中创建任务，选择持续复制模式，源库填写source，EasySearch 会自动将数据表转为索引。
注意：目标端为 EasySearch 时需要关闭数据验证，否则迁移任务会因兼容性问题失败。
EasySearch 初始化状态下只有默认索引。
启动任务后，DMS 自动创建了一个新索引newtable，映射 MySQL 的数据表。
打开索引，可以看到 MySQL 数据已转换为 EasySearch 的文档格式。
因为是 CDC 持续复制模式，我继续向 MySQL 插入新数据，模拟上游系统的实时写入。
EasySearch 这边几乎实时就收到了新数据，验证了迁移链路的连贯性。
本次实战中，借助 AWS DMS，我们实现了从 MySQL 到 EasySearch 的实时数据同步，具备以下优势：
虽然 AWS DMS 默认并不支持 EasySearch，但通过合理配置与兼容策略，我们依然实现了两者的高效打通。
如果你的业务需要将 MySQL 数据实时同步到 EasySearch，这套方案值得一试。
]]>虽然我一直很想 DIY 这样一款产品，开源的大多是 KVM-base 的方案，或者还有商业的 EXSI。毕竟个人精力有限，一直搁置到现在，然后随着事情越来越多，就购买了一台来玩玩，也脱胎换骨当甲方提需求。官网如下：https://lazycat.cloud/
机器是这样的，浓浓的机甲风格连，着运行了几天也一点都不烫。之前还担心炒豆子的问题，其实相对于白天的噪音几乎是没有的。
i5-1135G7，现在来看不算最新的，不过也比很多 NAS 强很多了，手动@群晖
32G 内存（只能一个盘位，所以加满了）
2.5 寸 2T 原装 HDD（预算有限，目前还在测试阶段，自带的盘是叠瓦盘，介意的话可以自己买盘替换）
neofetch 能看到是基于 Debian12 的。然后开发团队在上层构建自己的应用，只是 ssh 需要额外申请，不过一会就批了。
提供全平台的客户端，该有的都有了，这里开发适配应该花了不少时间吧。
MacOS 客户端的界面如下, 如果通过 web 访问就是这样，和传统的群晖有个主页不一样，这个更像是服务导向的，对于小白来说，只需要按照 Sass 的方式来使用，比如文件备份，时间机器，异地组网。而对于技术人员来讲，我个人觉得是更加吃力一些，要搞清楚每个服务是怎么启动的，怎么保证网络传输，怎么保证 HA，尽管懒猫团队已经实现了这些，但是出于职业习惯，还是希望抽丝剥茧，搞清楚从 Iass 到 Sass 的原理，然后学一学背后的哲学，以及在懒猫的商店上架自己应用，还有把应用接入懒猫的 SSO 系统。
关于服务嘛，是大多数玩家最喜欢的地方，有专门的 N 对 1 答疑，7*18 服务比 7 *24 听起来要靠谱很多，只能说专业，太专业了。团队是 deepin 二次创业出来的，都是技术流，所以懂用户，在群里可以做深度的技术答疑。在我之前的感受就是，玩 nas 的太多是爱好者，很多不懂 Linux 和开发，或者懂技术的都是理论派，对自己 host-server 或者 application 没有兴趣。以前的同事能因为这个结缘，由于彼此方向不同更多会集中在 Iass 和 network 的层面，而端对端的解决方案甚少。
但是懒猫让我看到了未来 nas 进化的方向，从硬件 - Iass -pass - Sass 做了全套的定制，也做了我一直想做而没有做完的事情，最早我的想发是在 Centos 上用 docker 跑很服务，然后用 NFS 做 share，然后用 KVM 做虚拟化层，然后用商业的方案做异地组网。尽管过过程十分坎坷，遇到了硬盘噪音，纯开源项目支持不到位，商业方案售后不专业等问题，最后就只在内网使用，走了很多弯路吧。
相信懒猫的这个价格，如果用 AWS 的话，最多半年就烧光 credit 了。有如此专业的团队来支持，治好了我的 NAS 焦虑。
文章来源：
下面是一个简单的 Nginx 配置示例，用于返回客户端的公网 IP 地址。
如果你希望 Nginx 直接返回客户端的 IP 地址，可以通过在location块中使用$remote_addr变量来实现。以下是一个完整的配置示例：
1 | server { |
listen 80;
监听 80 端口，处理 HTTP 请求。
location /get_ip { ... }
定义一个路径为/get_ip的请求处理块。当客户端访问/get_ip时，Nginx 会执行该块中的指令。
default_type 'application/json';
设置响应的默认 MIME 类型为application/json，确保客户端能够正确解析返回的 JSON 数据。
return 200 '{"ip_addr": "$remote_addr"}';
返回一个 HTTP 状态码为 200 的响应，内容为一个 JSON 对象，其中ip_addr字段的值为客户端的 IP 地址（通过$remote_addr变量获取）。
当客户端访问/get_ip路径时，Nginx 会返回如下格式的 JSON 响应：
1 | { "ip_addr": "客户端IP地址" } |
例如，如果客户端的 IP 地址是203.0.113.1，则响应为：
1 | { "ip_addr": "203.0.113.1" } |
通过以上配置，你可以快速搭建一个简单的 Nginx 服务，用于返回客户端的公网 IP 地址。这种方式不仅高效，还能根据需求进一步扩展功能，例如记录 IP 地址、限制访问频率等。如果你需要更复杂的功能，可以结合 Nginx 的其他模块和变量来实现。
]]>本教程将围绕 Basic Auth 认证机制展开，系统讲解如何通过 Nginx 实现安全防护、认证信息透传等常见配置场景，帮助你在多种实际部署环境中快速搭建可靠的访问控制机制。
无论你是在搭建家庭 NAS 服务，还是在企业环境中集成搜索引擎系统，本教程都能为你提供一套可落地、可复用的 Nginx 安全认证解决方案。
下面是我的 Nginx 配置文件示例。我们通过 Docker 启动 Nginx 容器，并将本地编写好的配置文件挂载到容器中，从而实现自定义的反向代理和认证逻辑：
1 | docker run -d \ |
default.conf配置如下:
1 | server { |
1 | server { |
80 端口（HTTP 默认端口）Host，这里是 localhost/）1 | location / { |
/ 会返回纯文本响应 "Nginx is running."，可用于验证 Nginx 是否启动正常。add_header Content-Type text/plain：指定响应内容为纯文本。/es/ 代理 EasySearch 后端服务1 | proxy_http_version 1.1; |
proxy_http_version 1.1：确保代理使用 HTTP/1.1，支持长连接。Host：保留原始请求的主机名。X-Real-IP / X-Forwarded-For：传递客户端真实 IP。X-Forwarded-Proto：传递原始协议（http / https）。Connection ""：用于避免默认的 keep-alive 设置引起错误（推荐保留）。1 | # proxy_set_header Authorization "Basic YWRtaW46MTIzNDU2"; |
admin:123456 的 base64 编码。可以根据需要开启。1 | add_header Access-Control-Allow-Origin *; |
/es/）。1 | rewrite ^/es/(.*)$ /$1 break; |
/es/ 前缀，转发给后端。例如：/es/_cat/indices 实际转发到 /cat/indices。break 表示在当前 location 中中止后续重写检查。1 | # location /static/ { |
/static/xxx.js 访问 Nginx 本地 /usr/share/nginx/html/static/xxx.js 文件。/es/ 前缀，则删除 rewrite 行。在启动服务后，当我们通过浏览器访问 Nginx 时，页面会弹出身份验证窗口。需要注意的是，这里的认证提示实际上来自后端的 EasySearch 服务，而非 Nginx 本身，说明请求中的认证信息未在 Nginx 层被处理或透传，因此由 EasySearch 发起了再次认证的要求。
在输入正确的用户名和密码后，我们可以看到 Nginx 成功代理请求，并返回了来自 EasySearch 的 API 响应，说明认证流程已顺利通过，后端服务正常可用。
如果希望由 Nginx 代为完成 EasySearch 的身份验证，也就是实现自动登录的效果，可以在配置文件中添加如下指令，将认证信息通过 HTTP 头部传递给后端：
1 | proxy_set_header Authorization "Basic YWRtaW46YWRtaW4="; |
其中，YWRtaW46YWRtaW4xMjM= 是使用 Base64 编码后的 用户名:密码 字符串（例如 admin:admin）。Nginx 在转发请求时会自动携带该 Header，从而实现对 EasySearch 的自动认证。
需要注意的是，Nginx 的配置文件修改后不会自动生效。为了确保配置被正确加载，需在每次更改配置文件后重启对应的容器服务。这是容器化部署中常见的操作流程，确保新配置被正确应用。
为了更直观地观察请求行为，我们使用了 Postman 进行测试。可以发现，即使在 Postman 中未显式添加任何认证信息，依然能够成功访问 EasySearch 集群。这说明前端未输入认证信息，但由于 Nginx 曾经缓存了认证状态，或配置了自动透传，导致后端依旧接收到了有效的认证头，从而允许了访问。
这种现象虽然在测试中提升了访问便利性，但在实际部署中可能带来安全风险，因此在生产环境中建议对认证流程进行严格控制，确保后端服务不会因为前端认证机制的疏漏而被绕过。
在一些教程中，常会提到一个名为 .htpasswd 的文件，它用于在 Nginx 层实现基本认证。当启用该机制后，Nginx 会对所有访问进行用户身份验证。
此时，是否将认证信息透传给后端服务，则由 proxy_pass_request_headers 参数决定。该参数默认值为 on，也就是说，当认证通过后，客户端发送的 Authorization 头部信息会被 Nginx 一并转发给后端服务。
为了验证这一行为，我编写了一个简单的 Flask 程序作为后端，用于观察请求中的 Header 内容。在真正将请求代理至 EasySearch 之前，我先让 Nginx 将请求反向代理到这个 Flask 应用，从而可以直观地查看是否存在 Authorization 头被透传的情况。
1 | from flask import Flask, request,abort |
这个是 flask 的打印的结果.
1 | Host: secure-nginx.orb.local |
为了解决双重认证的问题，我们启用了认证信息透传的配置(默认的 roxy_pass_request_headers on;)。启用该配置后，用户只需在访问 Nginx 时进行一次手动身份验证。Nginx 会将用户提供的凭证通过 HTTP Header 透传至后端的 EasySearch 服务，从而避免二次认证。当用户直接访问 EasySearch 时，依然需要单独输入凭证进行认证；但通过 Nginx 访问时，只需在前端认证一次即可完成整个请求流程。
1 | curl -k https://easysearch:9200 |
本次将 Nginx 的访问认证密码修改为 admin123 后，发现在请求过程中出现了两次身份验证的提示。具体表现为：当用户输入错误的密码时，Nginx 会首先返回一次 401 Unauthorized。由于 Nginx 与 EasySearch 使用了不同的认证信息，Nginx 在将请求头（包括 Authorization 字段）转发至 EasySearch 时，EasySearch 检测到凭据不匹配，也会返回一次 401。由此导致了双重身份认证失败的现象，影响了正常访问流程。
1 | curl -v -u "admin:admin" http://localhost/es/ |
| 场景编号 | Nginx 是否开启认证 | EasySearch 是否开启认证 | 实际认证次数 | 说明 |
|---|---|---|---|---|
| ① | 否 | 否 | 0 次 | 完全开放，任何请求无需验证。 |
| ② | 否 | ✅ 是 | 1 次 | 访问时直接弹出 EasySearch 的认证窗口，用户需输入凭证。 |
| ③ | ✅ 是 | 否 | 1 次 | 仅在 Nginx 层验证，验证通过后直接访问后端。 |
| ④ | ✅ 是 | ✅ 是 | 2 次（默认） | Nginx 和 EasySearch 各自认证，用户需连续输入两次密码。 |
| ⑤ | ✅ 是 | ✅ 是 | 1 次（透传,proxy_pass_request_headers on;） | Nginx 开启认证，并通过 proxy_set_header Authorization 透传给 EasySearch，用户仅需输入一次密码即可完成认证。 |
字数 1371，阅读大约需 7 分钟
都说 2024 是全闪 NAS 的元年，各个厂商也纷纷出品的自家的 NAS，独占鳌头的还是 QNAP 的TBS-h574TX，5 盘位 NVME，支持 10G 网口以及雷电网桥，甚至还有 12 代 i5 CPU 这个配置很难不让人心动。
使用 Qfinder Pro 可以查找局域网内的 QNAP NAS, 免去手动查找 IP 的麻烦,软件支持全平台。
Qfinder 寻找结果如下，可以识别出 NAS 名称，IP 地址，MAC 地址，机器型号以及系统及其版本。
除此之外，我们也可以在路由器后台寻找 IP 地址。
开始初始化流程：
进入 web 页面，开始安装系统
授权条款如下：
选择固件版本，为了快速安装，一般选择当前版本，然后进入 OS 内部再进行升级
设置 nas 名称和用户名,密码,由于系统内置了 admin 用户，所以这里不能使用 admin
设置时区以及 NTP 服务器同步时间。
设置 IP 地址，可以选择 DHCP 或者静态地址，我一般为了方便选 DHCP，这些后期都可以系统内部进行修改。
如果设置静态地址需要的参数如下：IP 地址，子网掩码，网关，DNS 服务器，不过还是建议直接在路由器上设置静态 IP 方便管理。
这个机器支持了雷电 4 的接口，原生支持了雷电网桥，所以这里多出来一个检测雷电的步骤，拔插雷电的时候机器会滴滴的响几声。
固件更新设置，建议设置通知，手动更新。
这个初始化的步骤会清除硬盘上的所有数据。
接下来就几分钟的等待，主要是等待往硬盘上安装软件，可以看到进度条。
这个机器的配置比较高，全程用了五分钟左右，这里主要启动 SMB 和系统的一些进程。
设置完毕之后，我们就可以使用 NAS 了。
使用之前设置好的用户名和密码进行登录
第一步需要设置存储池，用我们安装的 NVME 硬盘组成一个 raid 存储池。
RAID 通过将多个硬盘组合在一起，形成一个更大的存储单元，以实现数据冗余备份或提升存储性能。它是一种存储虚拟化技术，可以让系统同时从多个硬盘中读取和写入数据，从而提高读写速度。
RAID 的常见级别如下：
我只有两个 NVME，所以出于测试目的，组建了 Raid0。
设置存储池预留空间，快照预留空间以及警报阈值。
可以看到我的 4T 和 2T 的 NVME 组建的 RAID0 阵列， 设置完毕，除了保留空间外，最后之后 3.6T 可以用。
同样存储池也会清除磁盘上的所有数据。
存储池磁盘位一览：
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
存储池目录结构如下：
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
在用户管理处我们可以看到刚刚设置的用户，在这里也可以新建用户做一些额外的权限控制。
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
同时 NAS 还自带了监控，可以看到 CPU，内存以及磁盘使用率，还有运行时间，风扇转速，访问记录等等。
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
QuLog Center 是一款集中日志管理应用程序，可将详细的系统事件、系统访问和在线用户状态记录到您的设备。收集的信息可用于有效地诊断和理解设备系统问题，例如与用户访问相关的记录
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
QuLog 服务用于将日志传输到其他设备的 QuLog Center。您可以将其他设备的日志集中起来管理。
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
日志也可以发送到 Syslog 服务器：
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
如果想在公网上访问这个 NAS，那么也可以在路由器上设置端口转发，使用自家的 IP 地址进行访问。
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
全闪主要是风扇的声音比较大，用手机贴在上面测试了下，在 50 分贝左右，拿开一段距离的话在 40 分贝左右。有条件还是放在柜子里吧。
’ fill=’%23FFFFFF’%3E%3Crect x=’249’ y=’126’ width=’1’ height=’1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
]]>如果你是通过官方的 Docker Compose 部署 EasySearch，一般不会出现太大问题。但如果你像我一样在群晖或 NAS 上做过自定义配置，以下通用排查方法可以帮助你快速定位问题：
1 | version: "3" |
1 | docker ps -a | grep easysearch |
若容器状态为 Exited，说明启动失败。请查看容器日志进一步排查：
1 | docker logs <容器名> |
如果你看到了如下错误信息，而你使用的是自签证书，可以暂时忽略：
1 | javax.net.ssl.SSLHandshakeException: Empty client certificate chain |
进入容器内部查看：
1 | docker exec -it <容器名> bash |
期望看到监听地址为 0.0.0.0:9200 和 0.0.0.0:9300，说明服务对外暴露成功。例如：
1 | tcp 0 0 0.0.0.0:9200 0.0.0.0:* LISTEN 7/java |
检查 docker-compose.yml 中 ports 映射是否正确，或者用以下命令查看实际映射情况：
1 | docker ps |
确认是否已将容器内部端口映射到宿主机。
宿主机上也可以通过 netstat 或 ss 命令查看端口监听：
1 | netstat -tlnp | grep 9200 |
确保监听地址是 0.0.0.0:9200，而非 127.0.0.1。
-t：显示 TCP 连接-l：仅显示监听状态（Listening）的端口-n：以数字方式显示地址和端口（避免 DNS 解析）-p：显示监听端口的程序 PID 和名称使用 curl 测试：
1 | curl http://yourhost:9200 |
如需远程访问，需确认：
0.0.0.01 | ps aux | grep easysearch |
也可查看 nohup.out 或 logs 目录中的日志文件，看是否存在环境变量、路径错误、权限不足等问题。
1 | netstat -tulnp | grep java |
EasySearch 默认只监听本地，建议修改配置文件：
1 | # config/easysearch.yml |
确认 Linux 主机的防火墙设置：
1 | sudo ufw status |
确保目标端口（如 9200、9300）已允许外部访问。
云服务商（如 AWS、阿里云）通常还需配置安全组或防火墙规则，确保目标端口对外开放。
使用 dig 和 ping 测试域名解析与连通性：
1 | dig +short yourdomain.com |
可用 traceroute 进一步分析路径：(我在 MacOS 下测试的)
1 | sudo traceroute -P TCP -p 9200 192.168.X.X |
1 | 1. 服务是否启动？ |
无论是本地部署还是云端部署，掌握上述排查方法，你就能迅速定位并解决 EasySearch 无法访问的问题。
如果你觉得有帮助，也欢迎你将本文加入收藏夹，或转发给其他使用 EasySearch 的小伙伴 👇
而在 EasySearch 中，官方通过 initialize.sh 初始化脚本，大大简化了这些安全配置，启动时就能自动生成证书并开启密码保护。不过在一些测试或开发环境中，我们可能希望临时使用 HTTP + 无密码 的简化方式来调试。
本文将从配置文件入手，逐步说明如何启用或关闭认证、如何从 HTTPS 切换回 HTTP，以及如何开放外网访问。
当你执行 bin/initialize.sh 后，终端和 initialize.log 会输出初始化信息，其中包括自动生成的管理员账号密码，例如：
1 | curl -ku admin:160824cab0b02193226e https://localhost:9200 |
默认情况下，服务已启用 HTTPS 与密码认证。
配置文件位于：
1 | config/easysearch.yml |
可以在此文件中自定义集群名称：
1 | cluster.name: my-application |
修改前访问效果如下：
1 | curl -ku admin:160824cab0b02193226e http://localhost:9200 |
1 | "cluster_name": "easysearch", |
修改后再次访问：
1 | curl -ku admin:160824cab0b02193226e http://localhost:9200 |
1 | "cluster_name": "my-application", |
如果你希望让其他设备或公网访问 EasySearch，可以添加以下参数：
1 | network.host: 0.0.0.0 |
此外，为了提高对 Elasticsearch 客户端的兼容性，建议添加：
1 | elasticsearch.api_compatibility: true |
EasySearch 的安全配置由以下两个核心参数控制：
| 参数 | 作用 |
|---|---|
security.enabled | 是否启用认证（账号密码）和 HTTPS 模块 |
security.ssl.http.enabled | 是否启用 HTTPS（SSL/TLS 加密） |
security.enabled | security.ssl.http.enabled | 效果 |
|---|---|---|
| true | true | 默认配置，启用认证 + HTTPS（推荐） |
| true | false | 仅认证，无加密，使用明文 HTTP |
| false | true | 无认证，HTTPS 加密，仅适合特殊用途 |
| false | false | 最开放，HTTP + 无密码，不推荐生产使用 |
你可以根据实际需求选择是否打开加密或认证，适配测试与生产环境。
如果你修改配置为 security.ssl.http.enabled: false，即可使用 HTTP，但仍要求输入用户名密码进行访问：
1 | security.enabled: true |
访问效果如下图所示：
| 场景 | 推荐配置 |
|---|---|
| 本地测试（不加密、无密码） | security.enabled: false + security.ssl.http.enabled: false |
| 本地测试（仅加认证） | security.enabled: true + security.ssl.http.enabled: false |
| 安全访问（默认） | security.enabled: true + security.ssl.http.enabled: true |
| HTTPS 不认证 | security.enabled: false + security.ssl.http.enabled: true |
EasySearch 提供了灵活的配置方式，适合不同场景自由切换。对于开发者来说，理解这两个参数的作用，是快速上手运维的第一步。
提到认证,我们再看看如何修改密码,由于 Easysearch 默认新建了一个 admin 的用户,并且存在 config/security/user.yml 下
1 | --- |
这个我们也可以使用 postman 开调用 API.http://localhost:9200/\_security/account
1 | import requests |
新建用户
查看接口:https://localhost:9200/\_security/user
不过 yml 文件还是只有 admin,用 api 查看
使用新用户测试可以访问:
mysql -P 3306 -u admin -p -h mysqlsource.crtihcoeqzab.us-west-2.rds.amazonaws.com < people.sql
mysql -P 3306 -u admin -p -h mysqlsource.crtihcoeqzab.us-west-2.rds.amazonaws.com people
psql -h cloudacademylabs-targetcluster-0zdokkxbiyyh.cluster-ro-crtihcoeqzab.us-west-2.rds.amazonaws.com -U postgres -p 5432 people
]]>参考这个文档新建 google SSO（好像也没啥参考性）
https://developers.google.com/workspace/drive/api/quickstart/go?hl=zh-cn
创建客户端
填入信息，
然后在数据访问中添加权限 -
缺少的权限加在这里（如图），https://www.googleapis.com/auth/drive
在 coco-sever 更新 google drive 的信息
然后在 coco-server 中连接
跳转 google sso
由于是测试账户，所以会有这个弹窗，继续就好
再次进行测试
获取权限
显示登陆成功
然后可以在数据源中看到对应数据
说在前面，这个功能需要在语雀后台申请 Personal Access Token。使用的需要超级会员的（不是邀请新用户给的专业会员），所以需要付费使用。
然后在语雀后台，也就是https://www.yuque.com/settings/tokens处可以看见申请token的地方，如果你没有超级会员，这个是没办法用的。
点击新建，创建 token 分发权限，我这边给了所以的权限，语雀和 Notion 不同，这里给了权限就够了，其他地方无需在给权限。（手动@Notion 还要在文档或者文件夹授权）
点击查看详情可以看到 token，这里的 token 是可以反复查看的，由此语雀这一侧的设置完毕。
回到 coco-AI,我这边使用的是这个镜像，这里添加了对个人版本语雀的支持。
1 | infinilabs/coco:0.3.2_NIGHTLY-20250417 |
启动命令如下：
1 | docker run -d --name cocoserver -p 9000:9000 infinilabs/coco:0.3.2_NIGHTLY-20250417 |
然后进入后台初始化模型，我这里使用的本地部署的 deepseek：
点击数据源，选择 yuque connector
配置的地方很简单，填入数据源名称和 Token 和刷新时间。
然后我们就可以看到刷新的数据了
之前使用 Hugo Connector 接入和 hexo 和任意 Markdown，后来官方也支持了对于任意数据源的支持，主要是开放了这个接口：
具体操作如下：
设置 - conntor - 新增，让输入名称和描述等信息，新建出来 conntor
然后我们就能在数据源上的页面上看到刚刚添加的了 Customize Connector 了
点开提示，给了一个 API
然后我们去创建 token，如图
我这边使用 Postman 进行设置
如果你的请求没有带 token，就是这样的。
转成代码的是这样的，当然也可以开发自己的 agent。
1 | import requests |
在之前的文章中，我们让 Hexo，hugo 博客 支持了 coco AI 检索，也就是说我们还得使用客户端来检索，那是不是把搜索放在博客上呢？
Coco-AI 在 0.3 的版本中
先找一个 html 来看个效果。
1 |
|
1 | <div id="searchbox"></div> |
<div id="searchbox"></div>这是一个空的 div 元素，作为挂载容器。你的 searchbox 组件会被渲染进这个 div。
<div id="app"> 一样searchbox，用于后面初始化组件时绑定<script type="module">这表示：这是一个 ES Module 格式的 JavaScript 脚本。
import 加载其他模块、组件import { searchbox } from "http://localhost:9000/integration/cvmhvjl92jog2dokvsd0/widget";从远程地址（本地服务器）中导入 searchbox 函数：
说明这个 URL 返回的是一个 JavaScript 模块，里面导出了 searchbox
类似 Vue、React 中的组件库导入：
1 | import { Button } from "element-plus"; |
searchbox({container: "#searchbox"});调用 searchbox 函数，初始化组件，并挂载到页面中：
container: "#searchbox" 通过 CSS 选择器指定了上面那个 div就像你在网页上写：
1 | <div id="chat"></div> |
它就是在某个 div 中挂载一个聊天插件一样。你这段代码的本质就是嵌入并运行一个远程提供的 JS 组件。
这段代码的作用是：
把远程加载的
searchbox组件挂载到网页上的<div id="searchbox">中，完成动态插入功能。
如果你希望我反向帮你写出那个 searchbox 模块怎么写，或者做成本地文件测试，也可以告诉我~
下面是一个可以在任意网站自动嵌入你给出的 <div> 和 <script> 的油猴（Tampermonkey）脚本示例：
<body> 插入一个 #searchbox 的 divsearchbox 组件一开始打算在 hexo 的组件上改，但是在编译阶段有问题，索性使用油猴脚本来实现
1 | // ==UserScript== |
@match 改为具体的页面，例如：https://example.com/*这个油猴脚本的作用是：在任何网页上自动插入一个 div#searchbox 容器，并加载你提供的远程模块脚本，渲染搜索框组件。
1 | // ==UserScript== |
@name 是脚本的名字，显示在 Tampermonkey 的控制面板中。1 | // @namespace http://tampermonkey.net/ |
1 | // @version 0.1 |
1 | // @description 在任意网页中注入 searchbox 小部件 |
1 | // @author You |
1 | // @match *://*/* |
// @match https://example.com/*1 | // @grant none |
none。1 | // @run-at document-end |
DOMContentLoaded）。1 | (function () { |
1 | // 创建 searchbox 容器 |
<div id="searchbox"> 并插入到 <body> 中，作为挂载点。1 | // 动态加载模块脚本（ESM） |
<script type="module">，用来加载 ES 模块。1 | script.textContent = ` |
searchbox 组件searchbox({ container: "#searchbox" }) 初始化它1 | document.body.appendChild(script); |
<script type="module"> 插入到 <body> 中，触发模块加载和执行。这个脚本做了三件事：
div#searchbox#searchbox 上
先写吐槽
而铭凡这个厂家也是比较口碑两极化，这几年国产小主机层出不穷，minisforum 应该算是最早的一批。一部分玩家为了性价比方案选择国产小主机，而另一部分玩家还是只认电脑三巨头再加上 Apple。就比如雷神被吐槽是，一线的价格，二线的产品，三线的售后。（来自网络，不代表本人观点）
回到电脑本身，自带的 windows 真的卡，非常卡！！！！我是觉得实际办公都卡，跑 geekbeanch 也很卡。
然后换了 Ubuntu，网上说要根据 UFS 做一些更改，卖家也表示不支持除了 windows 以外的系统。但是我实际用的 ubuntu24.0，直接随身碟也装上了，安装时候也很卡，甚至不如大学的笔记本=。=，不确定是性能是在拉垮还是这几年 ubuntu 越来越臃肿了。
网上是这个方案，我先贴出来，Mark 一下。https://www.reddit.com/r/MiniPCs/comments/1eb8dgv/minisforum_s100_only_runs_windows_anyone_else/
1 | sudo mount --bind /dev "$PWD/dev" |
这是加了详细注释的版本（完全针对新手也能理解的程度）：
将 Ubuntu 系统的根分区挂载到/mnt 目录
（假设你已经挂载好了，这一步是之前完成的）
1 | # 进入挂载好的/mnt目录 |
挂载必要的系统目录，确保在 chroot 环境中能正常使用系统功能
1 | # 绑定/dev目录，这样chroot后能访问设备文件（如磁盘、终端等） |
切换到 chroot 环境，相当于“进入”你的 Ubuntu 系统中，像正常启动一样操作
1 | sudo chroot "$PWD" /bin/bash --login |
说明：
这样之后你在这个终端里的所有操作，都会直接作用于你挂载的 Ubuntu 系统上（而不是 LiveCD 或恢复环境）。
在 initramfs 的配置文件中添加模块，确保开机时加载 UFS 硬盘相关驱动
1 | echo "ufshcd" >> /etc/initramfs-tools/modules |
说明：
这里ufshcd和ufshcd-pci是 UFS 存储设备的驱动模块，如果不加，可能开机找不到硬盘导致无法启动。
更新 initramfs，将刚才加入的模块纳入系统启动时加载的内容
1 | update-initramfs -u -k all |
说明：
-u表示更新现有的 initramfs，-k all表示为所有内核版本更新。
这一步非常重要，否则刚才写入的模块不会生效。
退出 chroot 环境
1 | exit |
说明：
这会退出你刚才“进入”的 Ubuntu 系统，回到正常的恢复环境终端。
总结一句话
整个流程的作用是：
在离线状态下手动为 Ubuntu 系统补充 UFS 硬盘驱动，确保系统下次启动时可以识别和加载 UFS 硬盘，从而正常启动。
这个是在安装了 ubuntu 系统的 geekbench6 的跑分，这个是调整功耗到 9W 的，如果是默认的 6W 跑分只有 665，是完全没眼看的程度。期间也尝试过在 Bios 把功耗调整到 12.5W，但是分数反而降到 145 左右，不确定是不是降频或者功耗撞墙什么的。https://browser.geekbench.com/v6/cpu/11818077
改功耗：https://www.youtube.com/watch?v=g6Dk3BMgoYw程度
本来还想试试 openwrt 的，但是也没成功，UFS2.1 也没啥折腾的必要。用了前面修复 UFS 的命令，执行之后 boot 里也没有引导。
1 | sudo dd if=immortalwrt-24.10.0-x86-64-generic-ext4-combined-efi.img of=/dev/sda bs=4M status=progress |
如果追求桌面办公的话，适合对性能要求不高，能容忍卡顿的。
如果安装 Linux 的话，不强制追求 X86 话，还是树莓派吧，不过价格能够降一半倒是一个可以接受的方案。
这个能 POE 一线通固然是优点，但是 Typec 供电+wifi 网卡也没差太多。虽然放弱电箱真的好看好管理，但是 N100 对于现在的我来说，也就只能跑跑路由器系统或者轻 NAS 了吧。
]]>
据说是出口转内销，不过我的这个是纯中文版本。成品长这样，和 MT3000 很像 。
一下是刷了论坛上大分区的版本，如果想刷原版的 Openwrt，可以找客服要。
地址是 192.168.1.1，这个是原厂固件，几乎没什么用
在这里刷入过渡包
重启之后，连接电脑和路由器 LAN 口，手动配置为静态 IP 地址, 路由器默认 IP 是 192.168.1.1.
然后回出现登录页面，密码为空，直接登录
不保留当前配置
然后继续刷写
刷新之后自动跳转到这个页面, 登录进入到 openwrt 页面，密码 password
网页上传 uboot，打开 ttyd 刷入执行 mtd write /tmp/upload/mt7981_cudy_tr3000-mod-u-boot.fip FIP
电脑依旧更改静态 IP，长按 reset 按键，红灯闪烁即可松手进入 uboot 后台
这个是刷写之后的效果，可以看到 uboot mod
100 多元的小玩意，拿来做旁路由还可以，刷完之后发热也比原厂低了不少。
]]>设置里选择相机：
选择格式：
选择兼容性最佳：
然后 AirDrop 到 MacBook 上面，两个格式的图片大小差不多。
下一步就可以开心的把图片拖拽到笔记里了。
]]>
这里的 DHCP 池是上级路由器的一小部分，一是为了防止 IP 冲突，而是免费版只能 20 个客户端
首先要在 BIOS 上开启 PXE 启动，由于我的机器比较老，所以只能支持 legacy 的方式，启动之后是这样的：
然后在启动项中选择网络启动：
客户端自动寻找 PXE 服务端：
然后就会自动跳出这个页面：
在传输镜像的过程中并没有跑满 1G 内网，这个速度其实是不如大部分 U 盘的：
尝试下来，聊胜于无。
Ventoy 是个好东西，装机神器，iVentoy 就是它的网络版。这东西用起来倒也简单，扔几个 ISO 文件进去，设个 DHCP 启动池，启动服务，完事儿。听起来挺美好，可实际用起来嘛，总有点“理想很丰满，现实很骨感”的意思。
DHCP 池是从上级路由器里划出来的一小块，一来怕 IP 冲突，二来免费版只支持 20 个客户端。这就像你请客吃饭，桌子太小，只能坐 20 个人，再多就得站着吃了。站着吃也行，但总归不太舒服。
我的机器比较老，BIOS 里只能开 Legacy 模式，启动后就是这么个界面。看着这老古董，我心里有点感慨：科技这东西，跑得飞快，可我的机器还停留在上个世纪。启动时得选网络启动，像极了在旧书店里翻一本发黄的书，翻来翻去，终于找到了想要的那一页。
客户端会自动找 PXE 服务端，像一只迷路的小狗，东闻闻西嗅嗅，终于找到了回家的路。然后，屏幕上跳出这么个页面：
看起来挺顺利，可接下来的事情就不那么美好了。传输镜像时，速度没跑满 1G 内网，甚至还不如大部分 U 盘。这就像你开着一辆跑车，结果发现油门踩到底，速度还不如隔壁老王的自行车。
用下来，总结几点感受：
Windows 11 镜像没加载出来。可能是我的机器太老，老得连新系统都不愿意搭理它。这就像你去参加一个年轻人的派对，结果发现自己连门都进不去。
每次启动网启的提示闪很多遍。这玩意儿像个唠叨的老太太，一遍又一遍地提醒你：“别忘了网络启动！”可我只想干净利落地装个系统，不想听它啰嗦。
千兆网络速度跑不满。适合批量装机，但前提是你得有不急的耐心。这就像你去排队买票，队伍很长，但你又不赶时间，只好慢慢等。
总的来说，iVentoy 这东西，聊胜于无吧。它有点像那种“能用，但别指望太好用”的工具。如果你有耐心，又不介意它的那些小毛病，那它还是能派上用场的。但如果你追求的是高效、稳定，那它可能还差点意思。
最后，我想说，科技这东西，总是让人又爱又恨。爱它的便利，恨它的不完美。可正是这些不完美，才让我们有了继续折腾的动力。折腾吧，朋友们，生活不就是一场永无止境的折腾吗？
Ventoy 是装机的利器，iventoy 便是它的网络版。把 ISO 文件丢进目录，设定 DHCP 启动池，开机，完事。操作简便，适合批量装机。
但凡事总有些许不尽如人意。
DHCP 池呢，不过是从上级路由器分出的一小块地方，一是怕 IP 冲突，二是免费版只能给二十个客户端，这点倒是想得周到。
BIOS 里得先开 PXE，我这机器年纪大了，只认得 legacy 的启动方式，没办法。好不容易启动了，见到个画面，心里稍安。
接着得在启动项里选网络启动，设备便开始四处张望，寻找 PXE 服务器。等它找着了，蹦出来个界面，算是进了正题。
然而这装机过程，谈不上利落。镜像传输时，千兆网络竟跑不满，速度竟不及寻常 U 盘。Win11 的镜像更是直接消失，或许是我这老机器力不从心。每次启动时，那网启提示闪来闪去，晃得人头晕，哪有 U 盘插上就干脆利索？
尝试一番，感慨一句：聊胜于无。
]]>为了解决这个问题，我写了一个适配器（connector），并发布了对应的 Docker 镜像，来实现任意 Markdown 文件目录的元数据整理与 API 暴露：
👉 镜像地址：https://hub.docker.com/r/cloudsmithy/flask-markdown-connector
该 connector 的主要逻辑是：
如下图所示，我们会在每个 Markdown 文件开头添加或提取出 YAML 元数据：
使用以下命令即可快速拉起服务：
1 | docker run -d --name markdown-connector \ |
-d：后台运行容器；--name markdown-connector：指定容器名称；-p 1313:5000：将宿主机的 1313 端口映射到容器的 5000 端口；-v "$(pwd):/app/markdown"：将当前目录挂载进容器；--restart always：配置容器异常退出后自动重启；cloudsmithy/flask-markdown-connector：镜像名称。通过浏览器访问 http://localhost:1313/apidocs 即可打开内置 Swagger 文档。方便上层系统（如 Coco-AI）访问 Markdown 文件的元数据与内容。接口结构简洁直观，支持获取索引、刷新缓存、读取内容等功能。
GET /功能：返回服务启动提示信息
说明：用于检查服务是否正常运行
示例响应：
1 | { "message": "Markdown Connector is running." } |
GET /api/posts功能：获取生成的 index.json（缓存版）
说明：返回 Markdown 文件的路径与元数据列表，从缓存中读取，响应速度快
用途：Coco Server 可用作索引加载入口
示例响应：
1 | [ |
GET /index.json功能：实时渲染当前 Markdown 目录结构
说明：等价于 /api/posts，但是实时读取文件而非使用缓存，适合调试或手动使用
用途：确保数据为最新状态时使用
GET /api/refresh功能：重新扫描并生成最新的 index.json 缓存
说明：用于强制刷新目录索引，适用于新增 / 修改了 Markdown 文件后
响应示例：
1 | { "message": "Index cache refreshed." } |
GET /posts/功能：列出 Markdown 文件路径列表（不含元数据）
说明：返回所有可访问的 Markdown 文件路径，用于构建下拉菜单、快速跳转
响应示例：
1 | ["notes/linux.md", "dev/docker.md", "ideas/gpt-agent.md"] |
GET /posts/{filename}功能：获取指定 Markdown 文件的内容
参数：
{filename}：Markdown 文件路径（相对于挂载目录）用途：用于前端点击跳转后展示具体笔记内容
响应示例：
1 | { |
/api/posts 作为内容索引源；/api/refresh 后再拉一次 /api/posts 可确保内容最新；/posts/{filename}；在 Orbstack 中，我们可以清晰地看到本地 Markdown 文件已经映射到容器中：
接着我们将 connector 的服务地址填入 Coco Server 配置中：
你可以使用 /api/posts 或 /index.json 接口，它们返回的内容基本一致：
/api/posts 是来自缓存的接口；/index.json 是实时渲染本地文件结构。另外，通过 /api/refresh 还可以手动触发缓存刷新：
成功接入后，Coco Server 就可以读取 Markdown 文件的结构与元数据信息：
点击条目还可以跳转到对应的网页：
当然，和之前一样，也支持在搜索栏中直接搜索并跳转：
通过这个 Flask 版 Markdown Connector，我们可以将任意 Markdown 文件目录结构化暴露给 Coco-AI，实现：
这对于日常碎片化笔记管理来说，是一个非常轻量又灵活的解决方案。
]]>以下是官方推荐的 docker-compose 配置文件：
地址如下：
https://docs.infinilabs.com/easysearch/main/docs/getting-started/install/docker-compose/
1 | version: "3" |
错误提示：
1 | [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144] |
Lucene 搜索引擎在运行过程中需要创建大量内存映射文件(mmap)，而 Linux 系统默认的虚拟内存区域数量限制(65530)无法满足需求。
临时设置（重启失效）：
1 | sudo sysctl -w vm.max_map_count=262144 |
永久生效配置：
/etc/sysctl.conf 文件1 | vm.max_map_count=262144 |
1 | sudo sysctl -p |
错误信息：
1 | java.lang.OutOfMemoryError: Java heap space |
容器化环境中，JVM 默认的内存分配策略往往无法正确识别可用的系统资源，导致：
修改 docker-compose 配置，明确指定 JVM 堆内存：
1 | environment: |
配置建议：
这次是部署过程中踩的两个坑，写出来让大家避避雷。
]]>当然可以！💡 既然 Coco AI 依赖的是 Hugo 生成的 index.json 进行检索，那我们干脆在 Hexo 中实现 **相同结构的 index.json**，这样就可以直接复用 Hugo 的数据结构，避免字段不兼容导致的潜在 Bug。
接下来，我们将从 0 到 1 实现 Hexo 的智能检索功能！ 🚀
首先，我们需要安装 Hexo 并设置 Next 主题。
1 | pnpm install -g hexo-cli |
启动本地服务器：
1 | pnpm hexo s |
访问 http://localhost:4000/，确保 Hexo 站点运行正常。
1 | pnpm add hexo-theme-next |
修改 _config.yml：
1 | theme: next |
然后运行：
1 | pnpm hexo clean && pnpm hexo s |
访问 http://localhost:4000/，确认 Next 主题已生效。
hexo-generator-json-content我们需要安装 JSON 生成插件，用于输出博客文章数据：
1 | pnpm add hexo-generator-json-content |
这些添加到 _config.yml，确保 Hexo 生成完整的 JSON 数据：
1 | jsonContent: |
运行：
1 | pnpm hexo clean && pnpm hexo generate |
然后检查 public/index.json：
1 | cat public/index.json |
此时 JSON 已经生成，但 url 不是 Hugo 风格的，我们需要进一步优化。
index.json **默认情况下，Hexo 不会生成 /YYYY/MM/DD/slug/ 格式的 URL，因此我们需要手动调整。
scripts/generate_index_json.js在 Hexo 站点目录 下，创建 scripts/generate_index_json.js：
1 | hexo.extend.generator.register("index_json", function (locals) { |
index.json运行：
1 | pnpm hexo clean && pnpm hexo generate |
然后检查 public/index.json：
1 | cat public/index.json |
你应该会看到 JSON 变成：
1 | [ |
✅ 成功让 URL 变成 /YYYY/MM/DD/slug/ 格式！
既然 index.json 已经生成，我们可以像 Hugo 那样，在 Coco AI 里添加 Hexo 博客的检索。
在 Coco AI 里，点击 添加 Hugo Site，然后输入：
1 | http://host.docker.internal:4000/index.json |
如果想测试数据同步，我们可以修改同步时间为 1 秒，以便实时观察更新情况。
过了一会，我们可以在 Coco AI 界面看到博客数据已经同步，但前提是需要先添加模型！ ✅
Coco AI 的 KNN（近邻搜索） 会按照相关性对内容进行智能排序，使检索更高效！
| 步骤 | 命令 |
|---|---|
| 安装 Hexo 并切换到 Next 主题 | pnpm install -g hexo-cli && hexo init my-blog |
安装 hexo-generator-json-content | pnpm add hexo-generator-json-content |
修改 _config.yml | 让 Hexo 生成 index.json |
创建 scripts/generate_index_json.js | 确保 URL 变成 Hugo 风格 |
| 生成 JSON | pnpm hexo clean && pnpm hexo generate |
| 在 Coco AI 里添加 Hexo 站点 | 输入 http://host.docker.internal:4000/index.json |
🎉 通过本教程，你已经成功：
✅ 让 Coco AI 兼容 Hexo 博客，实现智能检索
✅ 复用 Hugo 的 index.json 结构，避免迁移成本
✅ 让 URL 变成 /YYYY/MM/DD/slug/ 以适配 Hugo Connector
✅ 在 Coco AI 里成功同步 Hexo 博客数据，并进行智能查询
💡 现在，你可以愉快地使用 Hexo + Coco AI 进行智能检索了！如果有 更多定制需求（如 author、word count），可以继续优化 generate_index_json.js！🔥🚀
要在本地或服务器上运行 Coco Server，可以借助 Docker 进行快速部署。
执行以下命令，快速启动 Coco Server（版本 0.2.2-2000）：
1 | docker run -d --name cocoserver -p 9000:9000 infinilabs/coco:0.2.2-2000 |
此命令将在后台运行 Coco Server，并将 9000 端口 映射到本机，以便通过 Web UI 进行访问。
如果希望数据在容器重启或删除后仍然保留，建议启用 数据持久化，操作步骤如下：
1 | mkdir -p $(pwd)/cocoserver/{data,logs} |
1 | docker run -d \ |
这样，所有 检索数据 和 日志信息 都会存储在 ./cocoserver/data 和 ./cocoserver/logs 目录下，即使容器重启，数据仍然可用。
如果你希望使用 docker-compose 进行更便捷的管理，可以采用以下 docker-compose.yml 文件：
1 | version: "3.8" |
运行以下命令启动 Coco Server：
1 | docker-compose up -d |
如需停止并删除容器，可执行：
1 | docker-compose down |
如果需要同时删除存储数据，则执行：
1 | docker-compose down -v |
成功部署 Coco Server 后，即可将 Hugo 站点 作为数据源进行智能检索。
在 Coco Server Web UI 中，进入 “数据源” 页面，并点击 “添加 Hugo Site”。
以 Pizza 官网 为示例，在输入框中填入相应的 URL 并保存。
配置完成后，Coco Server 会自动抓取 Hugo 站点的内容并进行索引。
完成 Pizza 官网的 Hugo 站点检索测试后，我们可以创建 自己的 Hugo 站点，并让 Coco Server 进行智能索引。
1 | brew install hugo |
1 | scoop install hugo-extended |
1 | sudo apt install hugo |
安装完成后，可运行 hugo version 确认是否安装成功。
1 | hugo new site my-hugo-site |
在 hugo.toml 文件中，添加 JSON 输出 配置：
1 | baseURL = "https://example.com/" |
在 layouts/_default/list.json 文件中，添加以下内容：
1 | [ |
1 | hugo server -D |
然后在浏览器访问：
1 | http://localhost:1313/index.json |
你将看到 Hugo 站点生成的 JSON 数据，例如：
1 | [ |
在 Coco Server 数据源管理 中，输入 Hugo 站点 JSON API 地址，例如：
1 | http://host.docker.internal:1313/index.json |
如果 Coco Server 运行在 Docker 内，而 Hugo 站点 运行在本机，则 localhost 访问可能会失效，此时应使用 host.docker.internal 访问宿主机。
添加成功后，Coco Server 会自动抓取并解析 Hugo 站点数据，实现智能检索。
通过本指南，我们已成功完成：
✅ 部署 Coco Server（支持 Docker / Docker Compose）
✅ 添加 Hugo Site 作为数据源
✅ 配置 Hugo 站点，生成 JSON API
✅ 让 Coco Server 索引 Hugo 站点，实现智能检索
现在，我们可以使用 Coco AI 高效检索 Hugo 站点内容，大幅提升信息查找效率！🚀
]]>本次发布的是 Coco AI 的首个预览版本，目前支持 MacOS 12 及以上操作系统。无论你是知识管理爱好者还是效率工具控，Coco AI 都值得一试。
Coco AI 分为客户端（APP）和服务端（Server），目前客户端仅提供 MacOS 版本，而服务端则支持 MacOS 和 Linux。今天，我们将重点体验客户端的使用。
首先，从项目主页或 GitHub 仓库下载 Coco AI 的安装包。安装过程简单直观，只需几步即可完成。
安装完成后，启动 Coco AI，你会在导航栏中看到它的图标。
在设置页面，你可以根据个人喜好进行一些基本配置，如设置自动启动、自定义搜索栏热键、以及是否跟随系统主题等。
默认情况下，Coco AI 会连接到 Coco Cloud。你可以选择登录以解锁更多功能。目前，Coco AI 支持通过 GitHub 和 Google 进行单点登录（SSO）。
登录成功后，系统会自动重定向到 Coco AI 的主界面。
登录后，Coco AI 默认会添加极限科技官方及相关衍生产品作为初始语料库。如果你有自己的服务器，还可以添加更多个性化的语料库，如 Google Docs、语雀、Notion 等。
Coco AI 的强大之处在于其 RAG（Retrieval-Augmented Generation）搜索功能。通过这一功能，你可以快速检索到自己之前撰写的文章或其他文档。
此外，搜索栏还可以作为一个站内聊天机器人使用，默认 Coco Cloud 的后端接入的大模型是 deeseek，进一步提升交互体验。
Coco AI 作为一款全新的 AI 搜索与效率工具，凭借其开源、跨平台、智能化等特性，为用户提供了极大的便利。无论是个人知识管理还是团队协作，Coco AI 都能胜任。期待未来更多功能的加入，也欢迎更多用户加入 Coco AI 的体验之旅！
]]>在《Coco AI APP 初体验：开启智能知识管理新篇章》和《打造智能语料库：通过 Coco AI Server 实现 Notion 笔记 RAG 检索功能》中，我介绍了 Coco AI 的第一个版本 ，我们我需要调用服务端的接口来手动添加数据源和配置登录信息，见那么在 0.2 的版本中，极限科技又开发了一个管理页面用来处理这些繁琐的信息。
同时这次更新也带来了全平台的支持，当然如果你愿意也可以自己编译源代码。
我们先来用 Docker 启动服务端，一行命令搞定，不需要再传递负载的命令行参数，也无需在启动 Easysearch。
1 | docker run -d --name cocoserver -p 9000:9000 infinilabs/coco:0.2.1-1998 |
服务启动在 9000 端口，那么在浏览器中打开欢迎页面：
创建账户，选择模型，和之前一样，我还是选择本地部署的 ollama 并且使用 deepseek 模型。
设置完成后我们看到主页面，我们的目的是添加数据源，这样就不用使用复杂的请求。
可以进一步设置 LLM 推理后端：
AI 助手这个功能还在开发中，后续可以期待一下。
连接数据源这里我认为是最大的亮点之一，不用再想之前改配置文件了，需要做的事情简单，以 Notion 为例简单填入 Token 和设置刷新时间即可。后按与 Notion 数据源的详细配置，可以回看之前写的《打造智能语料库：通过 Coco AI Server 实现 Notion 笔记 RAG 检索功能》
过了一会就可以在数据源中刷新出来的文档了，目前 Notion 只导入了标题，后期后导入具体内容的计划。
甚至还可以在这里进行搜索，小小的站内搜索吧。
然后回到客户端，进行登录，同时也支持暂时关闭不再需要的数据源。
登录这里不再需要手动抓 token 了，直接重定向，很方便。
登录之后，和之前一样检索，总体来说比之前省心很多。
我之前使用的是 0.1 的版本，再登录之后会遇到这个错误，只要重新安装最新版本的客户端就好了。
升级之后同样这个 chat 也进化了，还支持深度思考。由于这里我只导入了文档的标题，所以它也只给我回了文档。
这次更新体验直接提升了一大截，精简了很多配置，也简化了登录信息。感觉差不多下一步可以把这个服务部署到 NAS 上做日常使用了。
]]>
官方的公测声明如下：
通俗来说，这个虚拟机功能可以看作是一个精简版的 PVE（Proxmox Virtual Environment）。在使用时，磁盘和网卡建议选择 virtio，这是一种半虚拟化方案，能够提供更好的性能和兼容性。
磁盘部分推荐选择 virtio 驱动，以获得更好的 I/O 性能：
网卡同样支持 半虚拟化，可以在创建虚拟机时选择：
由于 Windows 默认不包含 virtio 驱动，因此需要手动下载并安装：VirtIO 官方下载地址
安装后，需要手动选择对应的驱动，这样才能正确识别到磁盘：
如果安装过程中未能识别到网卡驱动，可以在进入系统后再安装：
ISO 镜像中包含 Guest-tools，相当于虚拟机的 agent，需要安装，以提升性能和兼容性：
安装方式很简单，可以直接从 ISO 镜像里安装，里面包含所有必要的驱动和工具：
安装过程如下：
安装完成后，可以看到网卡已正常识别，并且协商速率为 10G：
测速结果表明，CPU 占用率相对较低，性能表现良好：
在内网环境下，测速几乎可以跑满 10G 网桥带宽：
总体来看，飞牛 OS 的虚拟机功能虽处于公测阶段，但体验已经相当不错。对于有轻量级虚拟化需求的用户来说，已经具备一定可玩性。如果你也对这项功能感兴趣，不妨动手试试！🚀
]]>PUT 和 POST 都用于创建或更新文档，但它们的使用方式和行为有所不同。理解这些区别并正确使用，可以避免常见的错误，并确保数据操作符合预期。PUT 用于创建或完全替换文档PUT 方法要求必须提供文档 ID，用于创建或完全替换已有文档。如果指定的文档 ID 不存在，则 PUT 会创建一个新文档；如果该 ID 已存在，则会完全覆盖原有数据，不会保留任何旧字段。
1 | PUT my_index/_doc/1 |
执行效果
1 存在，原有文档会被完全覆盖，只保留 myindex 字段。1 不存在，则创建一个新文档。1 | PUT my_index/_doc |
1 | { |
PUT 需要指定文档 ID，但该请求缺少 ID，导致错误。POST 用于创建或部分更新文档POST 既可以用于创建文档，也可以用于部分更新文档。其最大特点是可以省略文档 ID，让 Easysearch 自动生成唯一 ID。
1 | POST my_index/_doc |
如果要仅修改某个字段，而不影响其他数据，应该使用 _update：
1 | POST my_index/_update/1 |
age，不会删除 name 等其他字段。1 | POST my_index/_doc/1 |
POST 传入了指定 ID，但 POST 的默认行为是创建新文档，不适用于替换已有文档，可能会导致数据不一致。因此，**替换文档应使用 PUT，部分更新应使用 _update**。🚨 不推荐使用 POST 替代 PUT 进行替换，官方推荐：
PUT 明确用于创建/替换。POST 适用于新增（不带 ID）或部分更新（_update API）。POST my_index（省略 _doc）的错误解析1 | POST my_index |
1 | { |
这个是新建索引设置 mapping 的格式，不能用于创建索引数据。
✅ 正确做法
1 | POST my_index/_doc |
或者：
1 | PUT my_index/_doc/1 |
PUT 和 POST 的区别总结| 操作 | PUT my_index/_doc/1（替换） | POST my_index/_doc/1（不推荐） | POST my_index/_doc（创建） | POST my_index（错误） |
|---|---|---|---|---|
| 是否需要 ID | ✅ 需要 | ✅ 需要（不推荐） | ❌ 不需要（自动生成） | ❌ 不能直接 POST my_index |
| 文档是否存在 | ✅ 存在则完全替换 | ✅ 存在时完全替换（不推荐） | ✅ 创建新文档 | ❌ 报错 |
| 是否部分更新 | ❌ 不支持 | ❌ 不支持 | ❌ 不支持 | ❌ 报错 |
| 适用场景 | 创建/替换整个文档 | （不推荐） | 创建新文档 | ❌ 需要 /_doc |
为了保证数据的正确性和操作的高效性，推荐使用以下方式：
POST my_index/_docPUT my_index/_doc/{id}POST my_index/_update/{id}PUT my_index/_doc/{id}通过正确使用 PUT 和 POST，可以避免 POST my_index 这种格式错误，并正确管理 Easysearch 的索引和文档，确保数据操作符合预期。
💡 推荐大家在 Easysearch Console 进行实践，以更直观地理解这些区别！
🚀
easysearch-backups）。1 | { |
在 Easysearch 的 DevTools 执行：
1 | PUT _snapshot/my_s3_repository |
注意：
bucket需要填写你的 S3 存储桶名称。region需要替换成你的 AWS S3 所在区域，SDK 默认美东区。- 如果 Bucket 在中国区，还需添加
endpoint: https://s3.<region>.amazonaws.com.cn参数。
一旦 my_s3_repository 注册完成，就可以创建快照：
1 | PUT _snapshot/my_s3_repository/my_snapshot_001 |
查看当前存储的快照：
1 | GET _snapshot/my_s3_repository/_all |
当你需要恢复索引时：
1 | POST _snapshot/my_s3_repository/my_snapshot_001/_restore |
说明：这会从
my_snapshot_001还原my_index，但以restored_my_index命名，避免与现有索引冲突。
如果要直接覆盖原索引（确保 my_index 为空或已删除）：
1 | POST _snapshot/my_s3_repository/my_snapshot_001/_restore |
| 错误信息 | 可能原因 | 解决方案 |
|---|---|---|
repository_s3 plugin not installed | 没有安装 repository-s3 插件 | 运行 bin/elasticsearch-plugin install repository-s3 并重启 |
NoSuchBucket | S3 存储桶不存在 | 确保 S3 存储桶名称正确 |
AccessDenied | 权限不足 | 确保 S3 存储桶策略正确，检查 IAM 角色 |
index_closed_exception | 目标索引已关闭 | 先 POST my_index/_open 再恢复 |
index_already_exists_exception | 目标索引已存在 | 先 DELETE my_index 再恢复 |
1 | { |
1 | sudo ./bin/easysearch-keystore add s3.client.default.access_key |
1 | { |
1 | { |
1 | DELETE /my_index |
1 | POST /my_index/_close |
1 | POST _snapshot/my_s3_repository/1/_restore |
1 | { |
manage_snapshots 角色权限。.security 索引或全局状态，否则无法恢复。
1 | POST _snapshot/my_s3_repositor1/snapshot_002/_restore |
存储库用于存储快照，Elasticsearch 支持 AWS S3、GCS、本地等存储。
1 | GET _snapshot/_all |
示例返回：
1 | { |
1 | GET _snapshot/my_s3_repository |
1 | PUT _snapshot/my_s3_repository |
1 | DELETE _snapshot/my_s3_repository |
⚠ 删除存储库不会删除快照，需要手动删除快照！
快照用于备份和恢复索引数据。
备份特定索引
1 | PUT _snapshot/my_s3_repository/snapshot_001 |
备份所有索引
1 | PUT _snapshot/my_s3_repository/snapshot_002 |
1 | GET _snapshot/my_s3_repository/_all |
1 | GET _snapshot/my_s3_repository/snapshot_001 |
1 | DELETE _snapshot/my_s3_repository/snapshot_001 |
恢复已备份的索引。
1 | POST _snapshot/my_s3_repository/snapshot_001/_restore |
1 | POST _snapshot/my_s3_repository/snapshot_001/_restore |
1 | POST _snapshot/my_s3_repository/snapshot_002/_restore |
查询快照的执行状态。
1 | GET _snapshot/_status |
1 | GET _snapshot/my_s3_repository/snapshot_001/_status |
| API | 用途 |
|---|---|
GET _snapshot/_all | 查看所有存储库 |
GET _snapshot/my_s3_repository | 查看特定存储库 |
PUT _snapshot/my_s3_repository | 创建存储库 |
DELETE _snapshot/my_s3_repository | 删除存储库 |
PUT _snapshot/my_s3_repository/snapshot_001 | 创建快照 |
GET _snapshot/my_s3_repository/_all | 查看所有快照 |
GET _snapshot/my_s3_repository/snapshot_001 | 查看快照详情 |
DELETE _snapshot/my_s3_repository/snapshot_001 | 删除快照 |
POST _snapshot/my_s3_repository/snapshot_001/_restore | 还原快照 |
GET _snapshot/_status | 查看快照状态 |
🚀 通过本文，你可以高效地使用 AWS S3 进行 Easysearch 快照备份和恢复，并排查可能的错误，确保集群数据安全无忧！
]]>项目结构：
flask-demo/
├── app.py
├── requirements.txt
├── Dockerfile
├── start.sh
└── .github/
└── workflows/
└── docker.yml
app.pyfrom flask import Flask
app = Flask(name)
@app.route(‘/‘)
def hello():
return “Hello from multi-arch Flask Docker in production mode!”
requirements.txtflask
gunicorn
start.sh#!/bin/bash
WORKERS=${WORKERS:-4}
echo “🚀 Starting Gunicorn with $WORKERS workers…”
exec gunicorn -w “$WORKERS” -b 0.0.0.0:5000 app:app
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install –no-cache-dir -r requirements.txt
COPY . .
RUN chmod +x start.sh
CMD [“./start.sh”]
#!/bin/bash
set -e
IMAGE_NAME=”cloudsmithy/flask-demo” # Docker Hub 镜像名
PLATFORMS=”linux/amd64,linux/arm64” # 多架构支持
BUILDER_NAME=”multiarch” # buildx 构建器名
TAG=$(git describe –tags –abbrev=0 2>/dev/null || date +%Y%m%d)
echo “🔖 使用镜像 tag：$TAG”
echo “📦 构建并推送镜像：”
echo “ - $IMAGE_NAME:$TAG”
echo “ - $IMAGE_NAME:latest”
if ! docker info | grep -q “Username: cloudsmithy”; then
echo “🔐 正在登录 Docker Hub…”
docker login -u cloudsmithy
fi
if ! docker buildx inspect “$BUILDER_NAME” &> /dev/null; then
docker buildx create –name “$BUILDER_NAME” –use
else
docker buildx use “$BUILDER_NAME”
fi
docker buildx inspect –bootstrap
docker buildx build –platform “$PLATFORMS” \
-t “$IMAGE_NAME:$TAG” \
-t “$IMAGE_NAME:latest” \
–push .
在 .github/workflows/docker.yml 中创建以下内容：
name: Build and Push Docker Image
on:
push:
tags:
- ‘v*‘ # 仅在 tag push（如 v1.0.0）时触发
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: Checkout source code
uses: actions/checkout@v4
- name: Check DockerHub secrets
run: |
if [ -z “$“ ] || [ -z “$“ ]; then
echo “❌ ERROR: DOCKER_USERNAME or DOCKER_PASSWORD is missing”
exit 1
fi
- name: Set up QEMU
uses: docker/setup-qemu-action@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
with:
install: true # ✅ 自动创建默认 builder
- name: Docker login
uses: docker/login-action@v3
with:
username: $
password: $
- name: Extract tag name
id: vars
run: echo “TAG=${GITHUB_REF#refs/tags/}” >> $GITHUB_ENV
- name: Build and push Docker image (multi-arch + latest)
uses: docker/build-push-action@v5
with:
context: .
push: true
platforms: linux/amd64,linux/arm64
tags: |
cloudsmithy/flask-demo:$
cloudsmithy/flask-demo:latest
在仓库的 Settings → Secrets → Actions 中添加：
| Name | Value |
|---|---|
DOCKER_USERNAME | 你的 Docker Hub 用户名 |
DOCKER_PASSWORD | 你的 Docker Hub Token（推荐） |
git tag v1.0.0
git push origin v1.0.0
GitHub Actions 会自动：
构建支持 x86 + ARM 的镜像
推送到 Docker Hub：
cloudsmithy/flask-demo:v1.0.0cloudsmithy/flask-demo:latestdocker pull cloudsmithy/flask-demo:latest
docker run -p 5000:5000 cloudsmithy/flask-demo:latest
得到 Img 之后，点击映像，然后点击导入磁盘映像，我这里有两块盘，随便选一个就好。
选中上传的 img 文件上传到磁盘映像。
然后可以观察到群晖根据这个 img 正在创建卷文件。
这个是创建好的卷。
下面开始启动虚拟机，新增附近有一个三角箭头点击，有个导入的选项。（藏的挺深）
可以导入 OVA，也可以导入上面的磁盘映像。
同样也是选择磁盘。
唯一不同的是，在虚拟磁盘这里我们可以选择刚刚创建的硬盘映像，然后后面下一步就可以了，不再需要 ISO 啥的。
其实吧，在公有云这算基础操作，在群晖这藏的这么深。随便玩玩，差不多该有的都有了。
]]>登录 GitHub，导航至 Settings -> Developer settings -> OAuth Apps。
点击 New OAuth App，创建新的 OAuth 应用程序。
填写应用的基本信息，包括：
http://localhost:9000/oauth/callback）
创建应用后，系统将生成 Client ID 和 Client Secret。
这些凭证将用于 INFINI Console 的 OAuth 配置。
创建完成后，您可以在 OAuth 应用列表中查看应用的详细信息。
编辑 INFINI Console 的配置文件，添加以下 OAuth 配置：
1 | security: |
AllClusters 角色：用于管理集群的全局权限。
ReadonlyUI 角色：为只读用户分配受限权限。
打开浏览器，访问 http://localhost:9000。
点击 单点登录 按钮，进入登录流程。
点击 GitHub 图标，跳转至 GitHub 登录页面。
在 GitHub 授权页面，确认授权 INFINI Console 访问您的 GitHub 账户。
授权成功后，系统将自动跳转回 INFINI Console，并显示您的 GitHub 用户名。
通过以上步骤，您已成功将 INFINI Console 与 GitHub 的单点登录功能集成。此方案不仅简化了用户的登录流程，还通过 GitHub 的 OAuth 2.0 协议确保了身份验证的安全性。未来，希望 INFINI Console 进一步扩展角色权限管理，或集成其他身份提供者（如 Google、Microsoft 等），打造更加灵活的身份验证体系。
]]>在 INFINI Console 中，首先需要配置监控对象和通知渠道：
通过告警中心可以集中管理所有监控告警：
每个告警事件都提供详细信息查看功能：
系统完整记录所有历史告警信息：
以下是用 Python 实现的 Webhook 接收服务：
1 | from flask import Flask, request, jsonify |
在飞书客户端创建新的群组：
选择添加自定义机器人：
设置机器人名称和描述：
完成配置后获取 Webhook 地址：
通过以上配置，即可实现集群监控告警的实时通知，确保系统运维人员能够及时响应各种异常情况。
]]>在 ES 培训经常提到的 Elasticsearch Head 是一款基于浏览器的插件，适合不想部署 Kibana 等复杂工具的用户。它提供了简洁的界面，方便用户查看集群状态、索引分布、分片信息等。
索引分布查看
索引详细信息
分片信息查看
DSL 查询
Elasticvue 是一款高评分、高颜值的 Chrome 插件，功能全面，适合需要更丰富功能的用户。
节点信息查看
索引查看
DSL 查询
快照存储库管理
Cerebro 是一款需要自行部署的工具，建议使用 Docker 进行安装。为了避免端口冲突和 TLS 认证错误，可以通过 Gateway 进行转发。
1 | docker run -p 9100:9000 lmenezes/cerebro |
集群管理
网络请求处理
Cerebro 有自己的后端服务，请求并非直接从浏览器发出。因此，启动 Docker 容器时，避免连接 localhost，以免进入容器内部。
查看索引信息：
可视化功能一览：
对于需要密码认证的连接，可以使用以下两种方式：
直接连接：https://admin:xxxxx@localhost:9200/
Base64 编码凭证：
可以使用 Postman 或其他工具生成 Base64 编码的凭证，并在请求头中传递。
1 | import requests |
以上工具各有特色，用户可以根据自己的需求选择合适的工具。无论是简单的浏览器插件，还是功能更强大的 Cerebro，都能帮助您更好地管理和查询 Easysearch 集群。
]]>启动 Easysearch，这里把 Easysearch 作为语料库，把 notion 的素材存在 Easysearch
启动 ollama，使用 LLM 进行推理
启动 Coco Server，端口在 9000
Coco App 连接 Sever，输入输入
登录自己 server，依旧使用 Github 登录
Github 登录之后的重定向，我们目前需要抓取最后的, 后面用这个 token 换取访问 Coco Server AI 的 key：
1 | coco://oauth_callback?code=cupibub55o1cfqbveps0q804ai6aj14in3u91xjhvuk8s7ixirjsq2j9mmyyeut91nmgjwz0b494ngpk&request_id=eb94762b-f054-4710-9c6cf20889d3&provider=coco-cloud |
认证步骤如下：
会返回一个 Token,记录下来,这个是只是临时的, 如 XXABC
第二步:
curl -H’X-API-TOKEN: XXABC’ “http://localhost:9000/auth/request_access_token?request_id=dd9825e1-ebd3-4c84-9e3f-7ccb0421c508“
返回的才是你要的 Token
在 postman 中换 token，得到 access_token 和过期时间：
1 | import requests |
可以用 access_key 查看用户信息：
1 | import requests |
注册 Notion connector：
1 | import requests |
修改 Notion 配置文件，激活检索 Notion：
在 Notion 这个网站申请 API key，https://www.notion.so/profile/integrations
配置完成之后，设置权限和展示 apikey
配置 Notion Connector，这里需要用到 Notion 的 API Key:
1 | import requests |
需要在 Notion 中设置集成，这样 Coco Server 才会搜索到：
Coco server 日志中可以检索到 notion 了：
终于可以在搜索栏检索到了。
先新建 Github 的图床目标仓库：
然后设置 Token
打开 Github –> 点击头像 –> Settings –> Developer settings –> 点击 Personal access tokens –> 点击 Tokens(classic) –> 选择 Generate new token –> 填写 Note(token 名称)\选择过期时间\选择 token 权限 –> 点击 Generate token 保存 token
这个用来做上传图片的 Agent，实际上 Typora 和 Obsidian 都是调用了 PicGo 的 API
安装时候可能需要这个问题：
因为 PicGo 没有签名，所以会被 macOS 的安全检查所拦下。
安装后打开遇到「文件已损坏」的情况，请按如下方式操作：
信任开发者，会要求输入密码:
1 | sudo spctl --master-disable |
然后放行 PicGo :
1 | xattr -cr /Applications/PicGo.app |
然后就能正常打开。https://github.com/Molunerfinn/PicGo/blob/dev/FAQ.md
填入仓库信息和 token：
在 Typora 中设置上传图片时候调用 Picgo。
Obsidian 需要安装插件，先关闭安装模式：
安装 Image upload 插件：
Github 上可以看到 commit 记录：
Obsidian 也能正常渲染：
微信排版工具也能正常渲染 Github Raw 链接：https://doocs.github.io/md/
将移动硬盘连接至群晖 NAS（DSM 7.2），系统右上角立即弹出外接设备提示：
可在“控制面板 - 外接设备”中查看磁盘详情：
首次插入 exFAT 文件系统磁盘，系统提示需安装对应插件才能访问。可跳转 Package Center 安装 exFAT Access：
在 Mac 上格式化为 exFAT 后插入群晖，系统将其识别为两个分区：
为避免多分区问题，使用群晖内置“格式化”功能重新整理磁盘。可在外接设备列表中操作：
格式化为 exFAT 后，无论在群晖还是 Mac 上均可正常挂载与读写：
https://github.com/RROrg/rr/releases/
用 Etcher 来写盘，需要 U 盘引导的系统不适合用 Ventoy 启动，因为没办法保存，除非把系统安装在其他的磁盘上。
使用 web 版本的 findsnoloy 没有搜到机器，最后使用手机 app 搜到了局域网的安装好的群晖，之前安装在 ec2 上的黑群晖无法启动可能也是这个原因。
存储池信息：
手机 APP 连接的信息：
虚拟机也很好用，不输 EXSI（除了删除机器的时候强制输入密码）：
对于 VirtIO Block 控制器，官方只建议安装 Linux，实测也可以安装 Windows。
需要把官方的 guest agent 换成 VirtIO 的 ISO，对就是 fedora 那个：https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.266-1/
参考：
]]>
Easysearch 的运行依赖于 Java，程序启动时会自动从当前目录的 JDK 中查找 Java 环境。因此，即便环境变量中已经配置了 Java，程序也可能无法找到。针对这个问题，有两种解决办法：
下载 JDK 的二进制文件，将其重命名为 “jdk”，并放置在 Easysearch 的根目录下。
下载 Easysearch 的 bundle 包，该包会自带一个 JDK。下载链接为：https://release.infinilabs.com/Easysearch/stable/bundle/
安装步骤如下：首先执行初始化脚本，此脚本会设置 TLS 证书和集群密码。在执行脚本之前，log 目录为空。
1 | bin/initialize.sh |
这里打印了集群的密码和连接信息：
1 | curl -ku admin:db3e19a8c1c9f7755763 https://localhost:9200 |
然后启动集群，默认监听在 9200 端口：
1 | ❰xu❙~/Desktop/es/Easysearch-1.10.1-1978-mac-arm64-bundle❱✔≻ bin/Easysearch (base) 13:50:14 |
使用 Postman 尝试连接，可以正常返回 HTTP 的响应：
这里就需要用到上次的那个密码，默认存放在 log/initialize.log 下。
下载二进制文件并且运行，服务监听在 9000 端口，通过这个页面连接 Easysearch，用来替代 kibana，个人觉得比 kibana 和 OpenSearch Dashboard 要好用，除了 Easysearch 之外，还可以连接 ES 和 OpenSearch。
1 | ./console-mac-arm64 (base) 14:25:43 |
查看集群信息，可以看指标，也可以看索引，kibana 有的功能这边基本都有：
同时提供 DSL 查询：
INFINI Gateway 是一个面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway，可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。
Macbook 下有奇怪的安全规则，除了二进制文件之外，yml 文件经验也报错不安全。打开 “系统偏好设置”，进入 “安全性与隐私”，点击 “通用”，有 “仍然允许” 按钮，点击它即可。
然后按照 Easysearch 的配置进行修改，否则会连不上集群。就是这个报错：
1 | ./gateway-mac-arm64 (base) 14:51:14 |
修改配置文件之后，启动日志如下：
1 | ./gateway-mac-arm64 (base) 14:53:07 |
认证之后，可以从 Gateway 代理到 Easysearch：
注册时候用的是 2900 端口，如果注册到 8000 是无法连接的。
注册完成就会显示 Gateway 的信息：
本文围绕在 Mac 系统上安装、配置和使用 Easysearch 展开，详细介绍了各组件的安装过程、遇到的问题及解决办法，以下是详细总结：
在学习阶段缺少服务器时，可使用 Mac 进行 Easysearch 的安装学习，但官网未提供 Mac 版安装教程。Easysearch 运行依赖 Java，程序启动时会从当前目录的 JDK 查找 Java，即便环境变量已配置也可能无法找到，解决办法有：一是下载 JDK 二进制文件，重命名为“jdk”放在 Easysearch 根目录；二是下载自带 JDK 的 Easysearch bundle 包。
bin/initialize.sh脚本设置 TLS 证书和集群密码，初始化过程会提示覆盖证书和密码的风险，需确认是否继续，并可选择是否将凭证记录到日志文件。初始化成功后会显示集群的密码和连接信息，如curl -ku admin:db3e19a8c1c9f7755763 https://localhost:9200。bin/Easysearch，默认监听 9200 端口。启动过程中可能出现无法加载 JNA 本地支持库的警告，但不影响后续启动和使用。使用 Postman 尝试连接，需用到初始化时生成的密码（默认存放在log/initialize.log），可正常返回 HTTP 响应，验证了 Easysearch 集群的可访问性。
下载并运行二进制文件./console-mac-arm64，服务监听在 9000 端口，可替代 Kibana 连接 Easysearch、ES 和 OpenSearch。运行过程中会有部分警告信息，如重复的架构定义，但不影响基本功能使用，还可查看集群信息和进行 DSL 查询。
./gateway-mac-arm64，启动后各模块和插件依次启动，可实现索引级别的限速限流、缓存加速、查询审计等功能。认证后可从 Gateway 代理到 Easysearch，还可将 Gateway 注册到 Console。不过飞牛使用下来还是影音刮削的功能还是不错的，所以觉得把飞牛装在虚拟机里只使用影音的功能。
于是这个是一个使用群晖虚拟机安装飞牛 OS 的的过程。
在某个时间点的更新之后，群晖安装 debian 类虚拟机遇到问题，尽管看报错是正在加载，但是一直都没有响应。
在多次尝试之后，发现如下组合可以不卡代码，视频卡使用 vga，机器类型使用 Q35
查了下 GPT 的说法如下：
选项 说明 cirrus非常基础的显卡，兼容性强，但仅支持 800x600 或 1024x768 的低分辨率，性能差。 vga模拟标准 VGA，支持更多分辨率，但也比较基础。 vmvga模拟 VMware 的显卡，适用于装有 VMware Tools 的系统，和 Chromium/FnOS 相对兼容较好。
类型 说明 PC传统的 Intel i440FX 芯片组，兼容性强但比较老旧（类似 90 年代主板结构） Q35模拟 Intel Q35 芯片组，支持 PCIe、AHCI、现代硬件，推荐给新系统（如 Win10+、FnOS、Linux）
飞牛要直通两个盘，一个是系统盘，一个是数据盘。当然如果你只使用 SMB 做数据盘那也没问题，只是一直会提示你要加一个盘。
我主要使用影视，就只能安装在数据盘了，
创建媒体库，选择 SMB 文件夹：
缺点是这套不能直通核显给 FnOS，所以用浏览器看的时候 CPU 是满的，但是不耽误客户端解码。
当贝桌面下载飞牛 TV，然后使用手机飞牛账户绑定。
放了一个 4K 版本的哪吒，不卡顿～
我的方案是在打印机接群晖，然后使用 Docker 运行 Cups，来支持 Airprint。
虽然群晖自己支持了 cups，但是驱动不全，联想的打印机基本没有驱动，换几个其他的打印机型号也无法正确驱动起来，反而因为指令集冲突打印机一直在出空白页。
于是，打上了 docker 的主意。。。。
因为懒，也觉得没必要做数据映射：
1 | sudo docker run -d --name=airprint --net=host --privileged=true -e TZ="Asia/Shanghai" -e CUPSADMIN="admin" -e CUPSPASSWORD="pass" -e HOST_OS="Synology" -e TCP_PORT_631="631" chuckcharlie/cups-avahi-airprint:latest |
从 631 端口进去 web 页，
选择识别的打印机：
填写信息，选择共享这个打印机。
没有打印机的驱动，所以我选了兄弟的。
打印机信息一览：
一个小插曲：
Mac 升级之后把高级选项弄丢了，需要在这里邮件，选择自定义工具栏
要把 logo 拖放到 2 处而不是 1 处，这个设计很反人类。
主要原因是一开始使用其他的 docker 镜像无法识别打印机，所以在这里使用 http 和 ipp 添加
http 的这么添加：
ipp 的把这串输入到浏览器,MacOS 可以，手机和 Ipad 不行：
1 | ipp://192.168.5.171:631/printers/Lenovo_M7400_Pro |
这俩 docker 怎么都搜不到打印机（iPhone 不行，Window 可以，Mac 可以用上述办法添加），踩了几个小时的坑：
换了最上边那个容器之后全平台都可以了：
第二个就是我的打印机，第一个是群晖自己 cups 映射出来的，有 bug systemctl stop cupsd 也关不掉，不过也没啥影响。
MacOS 结果：
Iphone 默认无法选择打印机，只能点击分享，然后下拉菜单选择打印：
Iphone 默认只支持隔空打印，但是使用 Cups 之后我们的打印机不在列表中，但是也能正常的使用了。
整了这么多测试页，主打一个折腾开心：
最后还是有一个小问题，就是打印机由于关机或者拔掉 USB 的再重启的话，这个 docker 服务没有轮训机制，所以如果不常用的话，就需要每次打开打印机之后再手动运行重启下容器。
虽然现在的打印机都支持了 Airpint，cups 虽然已经成为了历史了，这么做算是圆了一个以前折腾的梦吧。
写了一个重启 CUPS docker 的 web：
1 |
|
后端使用 Flask：
1 | from flask import Flask, render_template, request, jsonify |
做好容器放在群晖上，完美～
1 | docker buildx build --platform linux/amd64 -t printer:latest --load . |
解决方式如下,在浏览器输入如下网址:
t.cn: 实测桔子酒店和重庆机场都能用
1.1.1.1:iphone 在重庆机场也能用
captive.apple.com:适用于 Apple 设备
上次在武汉机场也有提示, www.whairport.com
这次使用的是干粉灭火器，也只能覆盖火苗降低温度，然后还需要使用水来彻底灭火，使用起来很简单。需要提醒的是，使用的时候不要距离太近。
消防人员交了四字口诀“提拔握压”
提：单手提起灭火器，手提提把，保持水平垂直
拔：拔出保险销，注意另外一只手不要按到压把，否则无法拔出
握：握住喷管的最前端，控制好方向
压：压住灭火器的开关，喷出干粉灭火
体验了一次火灾模拟，每人分发了湿毛巾捂住口鼻（还是很呛），出来的时候感觉空气都是甜的。只能说烟熏比较火情更为恐怖。
除此之外，还有消防车的喷水演示，从图片中可以看到，这个射程还是很远的。
其实大多数人对火灾没啥概念，无非是偶尔看到哪里哪里又着火了之类的，还是防患于未然吧。
Markdown 使用 # 符号表示标题，# 的数量决定标题的级别，从一级标题到六级标题不等。
1 | # 一级标题 |
直接输入文字即为段落，段落之间需要空行隔开。行内换行需要在行尾加两个空格。
1 | 这是第一段。 |
Markdown 支持文本加粗、斜体及同时加粗斜体。
1 | _斜体_ |
效果：
斜体
加粗
*加粗并斜体*
使用 > 符号可以创建引用块，并且可以嵌套。
1 | > 这是一个引用。 |
无序列表使用 -、+ 或 * 作为列表标记。
1 | - 项目一 |
效果：
有序列表使用数字加 . 来表示。
1 | 1. 项目一 |
效果：
使用 [文本](URL "文本") 语法创建超链接，使用  插入图片。
1 | [Google](https://www.google.com "Google") |
行内代码使用反引号 ````，多行代码使用三个反引号包围，并且可以指定代码语言以启用语法高亮。
1 | def hello_world(): |
使用 | 和 - 创建表格，并通过 : 控制对齐方式。
1 | | 名字 | 年龄 | 性别 | |
效果：
| 名字 | 年龄 | 性别 |
|---|---|---|
| 张三 | 25 | 男 |
| 李四 | 30 | 女 |
使用 ---、*** 或 ___ 创建分割线。
1 | --- |
效果：
使用反斜杠 \ 来转义 Markdown 特殊符号。
1 | \*这是不被解析的星号\* |
效果：
这是不被解析的星号
Markdown 支持注脚功能，通过 [^注脚] 来实现，注脚内容放在文档底部。
1 | 这是一个带注脚的例子[^1]。 |
效果：
这是一个带注脚的例子^1。
Markdown 中可以创建任务列表，常用于跟踪任务状态。
1 | - [ ] 未完成任务 |
可以通过 # 创建文档内部的跳转链接，常用于创建目录或快速导航。
1 | [跳转到高级用法](#高阶用法 "跳转到高级用法") |
Markdown 支持 LaTeX 数学公式，可以通过 $ 或 $$ 来包围公式内容。
1 | 这是行内公式：$E=mc^2$ |
效果：
这是行内公式：
这是块级公式：
$$
\sum_{i=1}^n a_i^2
$$
借助 Mermaid，可以在 Markdown 中创建流程图或时序图等可视化内容。
1 | /Users/xu/Library/Containers/com.tencent.xinWeChat/Data/Documents/xwechat_files/wxid_neghhff72jo721_cb5c/temp/InputTemp/b699a258-8d44-4dbb-8c7c-ea70f37fa743.png```mermaid |
使用 <details> 和 <summary> 标签来实现可折叠的内容。
1 | <details> |
效果：
点击展开
这是隐藏的内容。
Markdown 的简洁、灵活和易读性，使其成为撰写文档的首选工具。通过本教程，你不仅能掌握 Markdown 的基本语法，还能利用其高级功能扩展文档的可读性和功能性。无论是编写博客、项目文档，还是生成结构复杂的技术手册，Markdown 都能够帮助你轻松完成任务。希望本教程对你有所帮助，助你在文档编写中更高效地应用 Markdown。
]]>最早接触的速食是 Soylent，准确的说应该是代餐，据说是一个程序员为了节约时间发明创造的产品，他那个时候没有 AIGC 时间都浪费在 debug 上了，所以从吃上来节省时间。无论是学生时代还是在帝都上班的时光里，这款产品的定位始终透露着吃不起的风格，而且国内一直没正规渠道卖过，只能海淘遂放弃。
海外的东西国内总有平替，这个叫做“若饭”，也曾疯狂追捧过，除了是为了腾出时间让老板过上更好的生活，要么就是外边的饭太难吃了。这个花样很多，固体的粉末的，还有其他口味以及能量棒什么的。总结下来就是真的吃不饱，起码两瓶才能保证没有饥饿感（好像也没有饱腹感），号称科学的添加了各种人体所需的营养，可以满足人体的需求。尽管这样，官方对他的定义仍然是建议每周保持几顿正常餐饮。不过在帝都，不吃几条街的馆子那就可惜了，遂放弃。
接下来是几款速食产品，单品不超过一顿饭的成本，按照时间顺序有蔡林记，阿宽，拉面说，牛肉河粉。至于速热米饭和自热锅，本来印象就不好，就不在这里再踩一遍了。
京东购入，打折的时候不到 10 元一包，当初也是被公司附近的小馆子逼到只能网上买吃的，公司的饮水机的热水永远也泡不完两碗热干面，个人也不是很喜欢酸豆角，即使每顿两碗，这个能量还是供应不上学习时候的用脑过度。连着吃几天还是会感觉身体营养不良。
小面味道不错，单价实惠，面皮吃了很上瘾，但是真的没啥能量，肚子饱了但是脑袋反应不过来，不能常吃，后来还是去同学家一口气吃了两三大碗米饭（排骨玉米汤）。
拉面说似乎是这里最高档的面了，这个是半干半鲜面，一半都需要煮上 6-8 分钟，再用开水冲开里面的料包，所以这个不适合在办公室吃，汤面多一些，拌面少一些。配料应该是速食界的天花板了，但是也抵不住疫情期间每天吃过的厌倦，真的不会再买了。另外狠狠的吐槽下和府捞面，除了宣传的书房里的拉面，其他都是严重掉粉，量上价格贵又难吃系列，貌似现在店里也是这种预知的餐盘，但是卫生问题仍然不能保证，工作人员素质问题有待提高。
本来方便面是不应该放在这里的，毕竟非油炸国产之光
个人心中的国产方便面排名： 五谷道场 > 汤达人 > 康师傅 > 其他
五谷道场兰州牛肉面和线下兰州牛肉面味道一模一样，辣子的味道能品尝出大西北的粗犷
线下 58 一碗的河粉尽管可以免费续面，但是单价还是很贵，于是超市购入一箱火车头河粉，还是面饼+汤料的搭配，只是这个价格赶超拉面说还是让人觉得没有下次了。味道嘛，以后还是去吃线下吧，大不了再多续几碗嘛～
女同事推荐的，山姆超市高档货，味道很浓郁，料包需要开水煮，我这砂锅煮了五六分钟打开看羊肉还有部分红血丝。不过味道不错，比上边同价位越南河粉好上不少。
Youtube 刷到了日清拉面创始人的故事，所以直接上网买了一堆，不过都没有青菜包，图片的肉片也是没有的，感觉还是拉王比较好吃，泡开了之后看起来很像日式拉面而是方便面，其他的泡开的和方便面没差。鸡汤拉面也很惊艳，用开水冲泡开就能直接收获一碗鸡汤面，生的面渣还能当作干脆面吃。出前一丁是日清的子品牌，其他都是杯面（基本上都是合味道），因为吃不饱就没有买。
这个就是日清拉王泡开的效果了，基本上看不出是方便面，再加上空气炸锅烤的鸡蛋简直完美～
价格上真的不值得，营养也不见得跟得上，还是好好吃饭吧～
]]>INFINI Console 是一个功能强大的数据管理和分析平台，其仪表盘页面提供了直观、简洁的界面，使用户可以快速了解系统状态并进行各种管理操作。本文将详细介绍仪表盘页面的各项功能。
仪表盘顶部显示了系统的实时告警、通知和待办事项的数量，当前数据显示：
这些指标有助于及时了解系统的异常情况和待处理的任务。
在仪表盘的中心区域，用户可以看到几项关键的系统概览信息：
仪表盘页面还提供了几个常用操作的快速入口，方便用户迅速访问常用功能：
仪表盘右侧显示了集群的动态信息，包括最近的操作日志。例如：
INFINI Console 是一个用于数据管理和分析的综合平台，其集群管理页面提供了对系统集群、节点、索引和主机的全面监控和管理功能。本文将详细介绍该页面的各项功能和特点。
集群管理页面主要分为几个部分：顶部的功能选项卡、中部的集群列表、以及右侧的筛选和排序选项。
页面顶部的功能选项卡包括以下几项：
集群列表展示了每个集群的详细信息，包括：
页面右侧提供了丰富的筛选和排序选项，可以根据以下条件筛选和排序集群：
节点监控：
索引监控：
主机的监控：
这里包括了常规的 CPU，内存，磁盘，网络的监控。
监控报表页面提供了对集群运行状况的详细监控和分析功能。本文将详细介绍该页面的各项功能和特点，帮助用户更好地理解和使用该工具。用户可以选择最近 15 分钟、1 小时、24 小时等不同时间范围查看数据。同时，用户可以手动点击刷新按钮更新数据，以获取最新的监控信息。
概览信息部分显示了当前集群的基本状态，包括：
监控报表页面还提供了多个性能指标的图表，包括：
当然也可以点击 Advance 查看更多的监控指标：
这个是是节点级别的性能监控，包括 CPU，负载，JVM 内存，剩余使用空间以及磁盘空间，集群启动时间和索引一些读写的情况。
这个是索引级别的监控，包括集群里有几个索引，索引状态是 open 还是 close，每个索引有几个主分片和副本分片，每个索引里文档的条数和占用空间，
集群动态页面提供了对集群中各类事件和活动的详细记录和监控功能。
别名管理页面提供了对索引别名的管理功能，使用户可以方便地管理和配置 Elasticsearch 的索引别名。
先来介绍下什么是别名以及基于别名的索引轮换：
别名（Alias）是 Elasticsearch 提供的一种机制，使用户可以为一个或多个索引创建一个或多个别名。由于 EasySearch 基于 Elasticsearch 开发，所以同样适用此功能。
可以通过 DSL 创建别名。例如，创建一个名为 my_index_alias 的别名指向 my_index：
1 | POST /_aliases |
删除一个别名同样可以通过 REST API 实现：
1 | POST /_aliases |
索引轮换是一种常用的索引管理策略，特别适用于日志和时间序列数据的场景。通过索引轮换，用户可以在索引达到一定条件（如大小或文档数量）时，创建一个新的索引来继续存储数据，而旧的索引可以继续用于查询。
current_write_index。首先，创建初始索引并设置写别名：
1 | PUT /my_index-000001 |
使用 /_rollover API 定义轮换条件并执行轮换：
1 | POST /current_write_index/_rollover |
此命令会检查 current_write_index 别名指向的索引是否满足轮换条件，如果满足，则创建一个新的索引（如 my_index-000002），并更新 current_write_index 别名指向新索引。
在轮换之后，所有的写入操作会自动指向新的索引 my_index-000002，而旧的索引 my_index-000001 可以继续用于查询操作。
可以通过一个独立的读别名来处理查询操作，例如 all_indices，该别名可以指向所有相关的索引：
1 | POST /_aliases |
通过这种方式，查询操作可以透明地访问所有的历史数据，而写操作总是指向最新的索引。在 INFINI Console 中提供了可视化创建索引以及别名的方式，页面右上角提供了新建按钮，用户可以通过点击该按钮创建新的索引别名，填写别名名称、关联索引、索引路由、搜索路由和过滤查询等配置。
平台概览页面中部展示了多个关键指标的监控图表，包括：
**健康状态 (Health)**：显示系统当前的健康状态。如果没有数据，则显示“暂无数据”。
**引擎分布 (Engines)**：展示系统中不同搜索引擎的分布情况，例如 EasySearch 和 Elasticsearch 的比例。图表显示当前 EasySearch 占 67%，Elasticsearch 占 33%。
**提供商 (Providers)**：显示系统中使用的云服务提供商信息。在示例中，所有资源都托管在 AWS 上。
**JDK 版本 (JDK)**：显示系统中使用的 JDK 版本信息。在示例中，所有节点都使用 JDK 版本 11.0.20。
磁盘使用情况 (Disk Utilization) - Top 10：显示磁盘使用率最高的前 10 个节点。在示例中，easysearch-node1 和 easysearch-node2 的磁盘使用率均为 4%。
JVM 使用情况 (JVM Utilization) - Top 10：展示 JVM 使用率最高的前 10 个节点。在示例中，infinilabs 集群的 easysearch-node1 和 easysearch-node2 节点的 JVM 使用情况有详细的时间序列数据，显示了不同时间点的使用率变化。
结下来是更加详细的页面，我们能够看到更多指标：
这个是 Discovery 的页面：
这里可以看到集群的警报，目前集群运行良好，没有任何警报。
内部会预设一些警报规则，如下：
点进去一个请求，比如磁盘的警告，可以到针对不同的使用量设置了不同的警告级别和警告通知。
这里针对警报设置警报，可以看到现在支持很多平台，Discord，飞书，邮件，微信，Slack 以及钉钉。
点击进去可以查看到，对于社交软件而言，其实是使用 Webhook 的方式进行通知，除此之外也支持配置邮件服务器和自定义的 webhook 进行通知。
接下来是开发工具，其实就是 kibana 的 dev tool，中文直译过来，使用上没有任何区别，除了支持 DSL 之外，还支持 SQL 查询。
这里可以看到连接这三个集群的凭证管理，目前都是有效的。
后台的用户授权，我这里目前设置了 admin，也可以在这里添加用户以及修改 console 管理界面的密码。
最后审计日子，会追踪对于集群做了什么操作，发出了哪些的 API 请求，可以看到我这里能看到捕获了查看集群监控信息以及查看集群索引的操作。
INFINI Console 的仪表盘页面集成了系统的关键信息和快捷操作入口，使用户可以高效地管理和监控系统。通过详细的概览信息、实时的告警通知、快速的功能入口和动态日志，用户能够对系统的运行状态一目了然，并快速响应各种管理需求。这个设计不仅提升了用户的工作效率，还确保了系统的安全和稳定运行。
INFINI Console 的集群管理页面提供了对系统集群的全面监控和管理功能。通过详细的集群信息展示、便捷的功能选项卡切换以及丰富的筛选和排序功能，用户可以高效地管理和监控系统中的集群状态。这不仅提升了运维效率，还确保了系统的稳定运行和高效管理。
INFINI Console 的节点管理页面提供了对集群节点的全面监控和管理功能。通过详细的节点信息展示、便捷的功能选项卡切换以及丰富的筛选和搜索功能，用户可以高效地管理和监控系统中的节点状态，从而提升运维效率，确保系统的稳定运行和高效管理。
INFINI Console 的监控报表页面提供了对集群运行状况的全面监控和分析功能。通过详细的概览信息和多个性能指标图表，用户可以高效地监控和管理集群的运行状态。这不仅提升了系统运维效率，还确保了集群的稳定运行和高效管理。
通过这些功能，INFINI Console 为用户提供了全面的系统管理工具，帮助他们高效地应对各种运维挑战，确保系统的高效、安全、稳定运行。
]]>服务器一般情况下默认参数都是很低的，而 Easysearch/Elasticsearch 是内存大户，所以就需要进行系统调优。
1 | sysctl -w vm.max_map_count=262144 |
vm.max_map_count 是一个 Linux 内核参数，用于控制单个进程可以拥有的最大内存映射区域（VMA，Virtual Memory Areas）的数量。内存映射区域是指通过内存映射文件或匿名内存映射创建的虚拟内存区域。
这个参数在一些应用程序中非常重要，尤其是那些需要大量内存映射的应用程序，比如 Elasticsearch。Elasticsearch 使用内存映射文件来索引和搜索数据，这可能需要大量的内存映射区域。如果 vm.max_map_count 设置得太低，Elasticsearch 可能无法正常工作，并会出现错误信息。
调整 vm.max_map_count 参数的一些常见原因：
支持大型数据集：
应用程序（如 Elasticsearch）在处理大型数据集时可能需要大量内存映射区域。增加 vm.max_map_count 可以确保这些应用程序有足够的内存映射区域来处理数据。
防止内存错误：
如果 vm.max_map_count 设置得太低，当应用程序尝试创建超过限制的内存映射时，会出现错误，导致应用程序崩溃或无法正常工作。
优化性能：
适当地设置 vm.max_map_count 可以优化应用程序的性能，确保内存映射操作顺利进行。
检查当前的 vm.max_map_count 值：
1 | sysctl vm.max_map_count |
或者查看 /proc/sys/vm/max_map_count 文件：
1 | cat /proc/sys/vm/max_map_count |
Elasticsearch 官方建议将 vm.max_map_count 设置为至少 262144。对于其他应用程序。
Easysearch 具体安装步骤见INFINI Easysearch 尝鲜 Hands on
使用 Amazon Web Services 控制台进行创建。
使用如下 docker compose 部署一个三节点的 ES 集群：
1 | version: "2.2" |
由于这个 docker compose 没有关于 kibana 的配置，所以我们还是用 Console 添加原生的 Elasticsearch 集群
集群信息
本次测试选择把索引快照备份到 Amazon S3，所以需要使用 S3 repository plugin，这个插件添加了对使用 Amazon S3 作为快照/恢复存储库的支持。
Easysearch 和 OpenSearch 集群自带了这个插件，所以无需额外安装。
对于自己部署的三节点 Elasticsearch 则需要进入每一个节点运行安装命令然后再重启集群，建议使用自动化运维工具来做这步，安装命令如下:
1 | sudo bin/elasticsearch-plugin install repository-s3 |
如果不再需要这个插件，可以这样删除。
1 | sudo bin/elasticsearch-plugin remove repository-s3 |
由于需要和 Amazon Web Services 打交道，所以我们需要设置 IAM 凭证，这个插件可以从 EC2 IAM instance profile，ECS task role 以及 EKS 的 Service account 读取相应的凭证。
对于托管的 Amazon OpenSearch 来说，我们无法在托管的 EC2 上绑定我们的凭证，所以需要新建一个 OpenSearchSnapshotRole，然后通过当前的用户把这个角色传递给服务，也就是我们说的 IAM:PassRole。
创建 OpenSearchSnapshotRole，策略如下：
1 | { |
信任关系如下：
1 | { |
然后在我们的 IAM user 上加上 PassRole 的权限，这样我们就可以把 OpenSearchSnapshotRole 传递给 OpenSearch 集群。
1 | { |
在源集群执行注册
1 | PUT /_snapshot/snapshot-repo-name |
在目标集群同样执行这个语句，为了防止覆盖源集群存储库的数据，将 “readonly”: true 添加到”settings” PUT 请求中，这样就只有一个集群具有对存储库的写入权限。
如果 Bucket 在中国区，那么还需要加上endpoint: https://s3.< region >.amazonaws.com.cn这样的参数。
1 | PUT /_snapshot/snapshot-repo-name |
对于 OpenSearch 来说，还需要执行 passrole，所以还需要添加role_arn这个字段，由于 IAM:PassRole 需要对 HTTP 请求做 signV4 日签名，所以这部常常使用 Postman 来完成。把角色传递过去之后，接下来的快照还原操作就可以在 OpenSearch Dashboard 中进行操作了。
需要注意的是，需要在 auth 这里输入 AccessKey，SecretKey，AWS Region，Service Name（es）来做 SignV4 的签名。
请求体如下：
1 | { |
GET _snapshot：这个命令返回所有已注册的快照存储库列表及其基本信息。1 | GET _snapshot |
1 | { |
GET _snapshot/es_repository：这个命令返回名为es_repository的存储库的详细配置信息，包括存储桶名称、区域和其他设置。1 | GET _snapshot/es_repository |
1 | { |
GET _cat/snapshots/es_repository?v：这个命令返回es_repository存储库中的所有快照及其详细信息，包括快照 ID、状态、开始时间、结束时间、持续时间、包含的索引数量、成功和失败的分片数量等。1 | GET _cat/snapshots/es_repository?v |
1 | id status start_epoch start_time end_epoch end_time duration indices successful_shards failed_shards total_shards |
1 | # PUT _snapshot/my_repository/<my_snapshot_{now/d}> |
根据快照的大小不同，完成快照可能需要一些时间。默认情况下，create snapshot API 只会异步启动快照过程，该过程在后台运行。要更改为同步调用，可以将 wait_for_completion 查询参数设置为 true。
1 | PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true |
另外还可以使用 clone snapshot API 克隆现有的快照。要监控当前正在运行的快照，可以使用带有 _current 请求路径参数的 get snapshot API。
1 | GET _snapshot/my_repository/_current |
如果要获取参与当前运行快照的每个分片的完整详细信息，可以使用 get snapshot status API。
1 | GET _snapshot/_status |
成功创建快照之后，就可以在 S3 上看到备份的数据块文件，这个是正确的快照层级结构：
需要注意的是， “base_path”: “
所以在 Open Search 中还原 Elasticsearch 就遇到了这个问题：
1 | { |
1 | POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore |
Elasticsearch 7.10.2 的快照可以还原到 Easysearch 和 Amazon OpenSearch
从 Easysearch 1.8.2 还原到 Elasticsearch 7.10.2 报错如下：
1 | { |
1 | { |
1 | { |
1 | { |
1 | { |
这是由于 Elasticsearch8 在创建快照的时候会默认加上一个 UUID 的字段，所以我们低版本的 Easysearch、Amazon OpenSearch 中会找不到这个字段，在执行GET _cat/snapshots/snap?v的时候就报错，及时在注册存储库的时候显示加上 UUID 的字段也无事无补。
1 | { |
以下是兼容性对比，每行第一列代表源集群，第一行代表目标集群：
| 快照兼容对比 | Easysearch 1.8.2 | Elasticsearch 7.10.2 | OpenSearch 2.13 |
|---|---|---|---|
| Easysearch 1.8.2 | 兼容 | 不兼容 | 不兼容 |
| Elasticsearch 7.10.2 | 兼容 | 兼容 | 兼容 |
| OpenSearch 2.13 | 不兼容 | 不兼容 | 兼容 |
Elasticsearch 的兼容列表官方的列表如下：
开始使用 Elastic Stack 和 Docker Compose：第 1 部分
https://www.elastic.co/cn/blog/getting-started-with-the-elastic-stack-and-docker-compose
Docker Compose 部署多节点 Elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docker.html#docker-compose-file
repository-s3 教程
https://www.elastic.co/guide/en/elasticsearch/reference/8.14/repository-s3.html
https://www.elastic.co/guide/en/elasticsearch/plugins/7.10/repository-s3.html
snapshot-restore
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/snapshot-restore.html
在亚马逊 OpenSearch 服务中创建索引快照
教程：迁移至 Amazon OpenSearch Service
https://docs.amazonaws.cn/zh_cn/opensearch-service/latest/developerguide/migration.html
]]>要使用 Elasticsearch Python 客户端，首先需要通过pip进行安装。打开终端或命令提示符，并运行以下命令：
1 | pip install elasticsearch==7.13.1 |
如果使用默认版本安装，会安装 8.x 的依赖，可能会报错 elasticsearch.UnsupportedProductError: The client noticed that the server is not Elasticsearch and we do not support this unknown product.
由于 Elasticsearch 7.10.2 以后变更了许可模式，引入了 Server Side Public License (SSPL) 和 Elastic License，很多基于 Elasticsearch 7.10.2 分支出来的搜索引擎需要使用 7.x 版本的 SDK 和 agent，比如 Beats 全家桶。
这是一个获取集群信息的 demo，使用es.cluster.health() 调用 Elasticsearch 集群的健康检查 API，返回集群的健康状态。
由于使用了自签名证书，所以在初始化时加上 verify_certs=False 参数，同时使用 warnings.filterwarnings("ignore") 设置 Python 的警告系统，忽略所有发出的警告。这在生产代码中通常不推荐，因为它会隐藏潜在的问题，但在开发或测试环境中，如果警告信息太多干扰调试，可能会暂时使用。
1 | import urllib3 |
在进行查询之前，我们需要在 Easysearch 中创建一些示例数据。
1 | # 定义示例数据 |
REST API 是与 Easysearch 进行通信的常用方式。通过 REST API，开发者可以发送 HTTP 请求来执行各种操作，包括索引文档、搜索数据等。以下示例展示了如何在 Python 中执行 REST 查询。
由于是 REST API，我们可以先使用 Postman 进行测试。
我们可以看到 HTTP 端点可以正常返回，然后就可以使用编程方式进行访问了：
1 | import requests |
DSL（Domain-Specific Language）是 Easysearch 的原生查询语言，允许用户构建复杂的查询。以下是一些示例：
1 | # 构建 DSL 查询 |
如果不指定 document ID，那么随机生成一个 ID 并写入。
1 | doc = {"field": "value4", "another_field": 9999} |
指定 ID 为 1 来手动更新索引：
1 | doc = {"field": "value4", "another_field": 9999} |
1 | # 更新单条数据 |
1 | # 删除单条数据 |
创建客户端实例后，我们可以使用 sql 方法执行 SQL 查询。以下示例展示了如何执行一个简单的 SELECT 查询。
1 | # 执行 SQL 查询 |
Bulk API 允许用户一次性对多个文档进行创建、更新或删除操作，极大提高了操作效率。以下是一些示例：
1 | # 定义批量插入数据 |
1 | # 定义批量更新数据 |
1 | # 定义批量删除数据 |
接下来，介绍索引创建、删除和检查索引是否存在操作。以下是一些示例：
1 | # 创建索引 |
1 | # 删除索引 |
1 | # 检查索引是否存在 |
Easysearch 虽然没有专门的 Python SDK，但完全兼容 ES 7.x 的 Python SDK 客户端，这为开发者提供了极大的便利。通过使用 ES 7.x Python SDK，开发者可以轻松地使用 DSL 和 SQL 语法对 Easysearch 进行查询和数据操作。Easysearch 主要优势包括：
Easysearch 结合 ES 7.x Python SDK 的强大功能，为开发者提供了一个高效、灵活的大数据处理平台。无论是执行简单的 SQL 查询，还是构建复杂的 DSL 查询，都能满足各种数据分析需求。如果您正在寻找一个强大的搜索和分析解决方案，Easysearch 绝对值得一试。它不仅能帮助您更高效地处理和分析大数据集，还能为数据驱动的决策提供有力支持。
]]>Elasticsearch 是一个基于 Apache Lucene 的开源分布式搜索和分析引擎，它被广泛应用于全文搜索、结构化搜索和分析等多种场景中。作为 Elasticsearch 的国产化替代方案，Easysearch 不仅保持了与原生 Elasticsearch 的高度兼容性，还在功能、性能、稳定性和扩展性方面进行了全面提升。对于开发团队来说，从 Elasticsearch 切换到 Easysearch 不需要做任何业务代码的调整，确保了无缝衔接和平滑迁移。
Easysearch 是基于 Elasticsearch 7.10.2 开源版本二次开发，所以支持 Elasticsearch 原始的 Query DSL 语法，基本的 SQL 语法，并且兼容现有 Elasticsearch 的 SDK，使得应用无需修改代码即可进行迁移。其平滑的迁移特性，如基于网关的无缝跨版本迁移与升级，提供了随时安全回退的能力。
在之前的文章中，我们已经介绍了 Easysearch 的搭建 和 可视化工具的使用，今天我们将探讨 Easysearch 集群的基本概念和常用的 API。
Easysearch 集群由以下几个核心概念构成：
通过多个 API，例如 _cluster/health 和 _cluster/stats，用户可以轻松查看集群的健康状态和详细信息，这些信息对于维护和优化 Easysearch 集群至关重要。
无论是在性能的提升，还是在功能的兼容性方面，Easysearch 都为用户提供了一个强大的搜索引擎平台，让从 Elasticsearch 到 Easysearch 的迁移变得无缝且高效。掌握其核心概念和 API 的使用，将帮助开发者更好地利用这些工具来构建和优化他们的搜索解决方案。
在 Easysearch 中，可以通过多个 API 来查看集群的各种信息，包括集群的健康状况、节点信息和索引状态。以下是一些常用的查看集群信息的 API 和示例：
_cluster/health API 可以查看集群的健康状态，包括集群是否处于正常状态、节点数量、分片状态等。
1 | GET /_cluster/health |
示例响应：
1 | { |
_cluster/stats API 可以查看集群的详细状态，包括索引、节点、分片等信息。
1 | GET /_cluster/stats |
示例响应：
1 | { |
_nodes API 可以查看集群中节点的详细信息，包括节点角色、IP 地址、内存使用情况等。
1 | GET /_nodes |
示例响应：
1 | { |
_cat/indices API 可以查看集群中所有索引的状态，包括文档数、存储大小、分片数等信息。
1 | GET /_cat/indices?v |
示例响应：
1 | health status index uuid pri rep docs.count docs.deleted store.size pri.store.size |
这些 API 可以帮助你全面了解 Easysearch 集群的状态和健康状况，从而更好地管理和维护集群。
在 Easysearch 中，增删改查操作是管理数据和索引的基本功能。以下是如何使用这些操作的详细示例。
创建一个新的索引，并指定分片和副本的数量：
1 | PUT /my_index |
删除一个不再需要的索引：
1 | DELETE /my_index |
通过 POST 或 PUT 请求向索引中添加文档：
1 | POST /my_index/_doc/1 |
1 | PUT /my_index/_doc/1 |
POST 和 PUT 方法用于不同的操作，尽管它们都可以用于添加或更新文档，但它们的行为有所不同。
POST /my_index/_doc/1 方法用于创建或替换一个文档。如果指定的文档 ID 已经存在，POST 请求将更新整个文档（不会合并字段）。如果文档 ID 不存在，它将创建一个新的文档。
1 | POST /my_index/_doc/1 |
PUT /my_index/_doc/1 方法通常用于创建一个新的文档，或者完全替换一个已存在的文档。与 POST 类似，如果指定的文档 ID 已经存在，PUT 请求将替换整个文档。
1 | PUT /my_index/_doc/1 |
使用场景：
POST：更适合用于添加或部分更新文档，即使文档 ID 已经存在。PUT：更适合用于创建或完全替换文档。ID 自动生成：
POST 请求可以不提供文档 ID，此时 Easysearch 会自动生成一个文档 ID。PUT 请求必须提供文档 ID，如果未提供，则会返回错误。部分更新：
POST 请求可以用于部分更新（通过 _update API）。PUT 请求用于完全替换文档，不支持部分更新。如果文档 ID 已经存在，POST 和 PUT 都会覆盖整个文档，并且效果是一样的。但是，通常 POST 用于提交数据，而 PUT 用于上传和替换资源。
POST 方法添加或更新文档：1 | POST /my_index/_doc/1 |
PUT 方法添加或更新文档：1 | PUT /my_index/_doc/1 |
在这两个示例中，结果都是在索引 my_index 中创建或更新文档 ID 为 1 的文档。无论使用 POST 还是 PUT，如果文档 ID 已存在，都会覆盖原有的文档内容。
使用 _create 方法新建文档，如果文档已经存在则返回错误：
1 | PUT /my_index/_create/1 |
如果尝试新建已存在的文档，将会出现如下错误：
1 | { |
通过 ID 获取文档的详细信息：
1 | GET /my_index/_doc/1 |
更新文档的特定字段，保留原有字段：
1 | POST /my_index/_update/1 |
通过 ID 删除指定的文档：
1 | DELETE /my_index/_doc/1 |
查询索引中的所有文档：
1 | GET /my_index/_search |
这个是《老杨玩搜索》中总结的图，可以作为“小抄”来记忆：
_bulk API 用于在一次请求中执行多个索引、删除和更新操作，这对于批量处理大规模数据非常有用，可以显著提高性能和效率。以下是 _bulk API 的基本使用示例：
1 | POST /my_index/_bulk |
_bulk API 的请求体由多个操作和文档组成。每个操作行包含一个动作描述行和一个可选的源文档行。动作描述行指明了操作的类型（例如，index、create、delete、update）以及操作的元数据。源文档行则包含了实际的数据。
每个操作之间需要用换行符分隔，并且请求体最后必须以换行符结尾。
1 | POST /_bulk |
在 Easysearch 中，分词器（Analyzer）用于将文本分解为词项（terms），是全文搜索和文本分析的基础。分词器通常由字符过滤器（Character Filters）、分词器（Tokenizer）和词项过滤器（Token Filters）组成。以下是关于分词器的详细介绍：
只有 text 字段支持全文检索，返回的结果根据相似度打分，我们一起看下
1 | POST /index/_mapping |
POST /index/_mapping
index的索引添加或更新映射设置。“properties”:
properties定义了索引中文档的字段结构。在这个例子中，定义了一个名为content的字段。“content”:
content的字段。“type”: “text”
type字段指定content字段的数据类型为text。text类型适用于需要分词和全文搜索的字段。“analyzer”: “ik_max_word”
analyzer字段指定索引时使用的分词器为ik_max_word。ik_max_word是 IK 分词器中的一种，它会尽可能多地将文本分解为更多的词项。“search_analyzer”: “ik_smart”
search_analyzer字段指定搜索时使用的分词器为ik_smart。ik_smart是 IK 分词器中的另一种，它会更智能地进行分词，以提高搜索的准确性。当然，在设置这个 mapping 的时候可以使用同样的分词器，也可以使用不同的分词器。这里介绍下 IK 分词器：
ik_max_word和ik_smart。ik_max_word：将文本尽可能多地切分成词项，适用于需要更高召回率的场景。ik_smart：进行最智能的分词，适用于需要更高精度的搜索场景。这个 DSL 的设置意味着，在向这个索引添加或更新文档时，content字段的文本会使用ik_max_word分词器进行分词处理，以确保文本被尽可能多地切分成词项。而在搜索时，content字段的文本会使用ik_smart分词器进行分词处理，以提高搜索的准确性和相关性。
以下是关于 standard，ik_smart，ik_max_word 这几个分词器的对比：
1 | GET /_analyze |
结果如下：
1 | # GET /_analyze （standard） |
如果使用了不存在的分词器会出现这个错误。
1 | { |
在 Easysearch 中，精确搜索、正则表达式搜索和通配符搜索是三种不同的搜索方式，各有其应用场景和特点：
**精确搜索 (Term Query)**：
1 | { |
**正则表达式搜索 (Regexp Query)**：
1 | { |
**通配符搜索 (Wildcard Query)**：
?（匹配单个字符）和 *（匹配零个或多个字符）。1 | { |
接下来看这个例子，我们将使用批量导入数据，然后进行几种不同类型的查询，包括精确查询、通配符查询和正则表达式查询。
1 | POST /users/_bulk |
1 | GET /users/_search |
1 | GET /users/_search |
1 | GET /users/_search |
通过这些例子，你可以看到如何在 Easysearch 中使用批量导入数据，然后使用各种查询方法来检索特定条件的数据。这些查询方法可以帮助你高效地搜索和分析数据，以满足不同的业务需求。
这里同样是《老杨玩搜索》中总结的“小抄”来方便记忆：
在 Easysearch 中，多字段查询允许您在多个字段上同时执行搜索，以获取更精确的结果。最常用的多字段查询类型是 multi_match 查询。multi_match 查询是 match 查询的扩展，能够在多个字段中搜索指定的关键词。
multi_match 查询支持多种匹配模式，如 best_fields、most_fields、cross_fields、phrase 和 phrase_prefix。以下是各模式的简要介绍：
我们先导入一些示例数据到一个索引 documents 中：
1 | POST /documents/_bulk |
我们将使用 multi_match 查询在 title 和 content 字段中同时搜索关键词。
1 | POST /documents/_search |
best_fields**：1 | POST /documents/_search |
most_fields**：1 | POST /documents/_search |
cross_fields 模式：1 | POST /documents/_search |
1 | POST /documents/_search |
1 | POST /documents/_search |
best_fields。使用 multi_match 查询，您可以在多个字段上同时执行搜索，获得更精确和全面的结果。通过指定不同的匹配模式，您可以调整查询行为以满足特定的搜索需求。无论是基本关键词匹配、短语匹配还是跨字段匹配，multi_match 查询都提供了强大的功能来处理复杂的搜索场景。
除此之外，还可以使用 boost 参数用于调整特定字段的权重，从而影响搜索结果的相关性评分。multi_match 查询支持为不同字段设置不同的 boost 值，以便在搜索结果中优先显示某些字段的匹配项。
布尔查询是 Easysearch 中非常强大且灵活的一种查询方式，它允许用户通过组合多个查询条件来实现复杂的搜索需求。布尔查询使用 bool 查询类型，可以包含以下几种子句：must、filter、must_not 和 should。每种子句都有其特定的用途和语义。
must 数组中的查询条件必须匹配，类似于逻辑上的 AND 操作。filter 数组中的查询条件必须匹配，但它不会影响评分。filter 子句通常用于对性能要求较高的过滤操作，因为它不计算相关性评分。must_not 数组中的查询条件必须不匹配，类似于逻辑上的 NOT 操作。should 数组中的查询条件至少匹配一个。must 子句，则至少要匹配一个 should 子句。should 子句在计算相关性评分时也有影响。should 子句中至少需要满足的条件数量。
首先，我们需要创建一个名为books的索引，并定义它的映射（mappings）。映射用于指定每个字段的数据类型。在这个例子中，类别和书名字段都被定义为keyword类型，这是因为我们需要进行精确匹配查询。
1 | PUT /books |
接下来，我们使用批量操作（bulk API）将一些示例数据导入到books索引中。这些数据包括不同类别的书籍。
1 | POST /books/_bulk |
现在，我们使用布尔查询来搜索类别为“文学”并且书名为“我的阿勒泰”的文档。这里使用的是must子句，表示查询结果必须满足所有条件。
1 | POST /books/_search |
我们还可以使用filter子句来执行相同的查询。filter子句用于过滤文档，且不会影响文档的相关性评分。这在不需要计算相关性评分时可以提高查询性能。
1 | POST /books/_search |
当我们执行上述查询时，期望返回的结果是books索引中类别为“文学”且书名为“我的阿勒泰”的文档。无论是使用must还是filter子句，结果应该都是：
1 | { |
1 | POST /_search |
must 子句：必须匹配的条件，文档必须包含user.id为kimchy。filter 子句：过滤条件，文档必须包含tags为production，但不会影响评分。must_not 子句：不匹配的条件，文档的age字段不能在 10 到 20 之间。should 子句：可选匹配条件，至少需要匹配一个should子句中的条件。这里要求tags字段匹配env1或deployed。minimum_should_match**：至少需要匹配一个should子句中的条件。boost**：提升查询的整体评分。为了展示这个 DSL，我们需要创建一个索引并导入一些数据。假设我们要在 Easysearch 中创建一个索引users，并插入一些测试数据。
创建索引
1 | PUT /users |
批量导入数据
1 | POST /users/_bulk |
接下来执行布尔查询：
1 | POST /users/_search |
根据以上查询，预期返回的结果应该符合以下条件：
user.id必须是kimchy（由must子句决定）。tags必须包含production（由filter子句决定）。age字段不在 10 到 20 之间（由must_not子句决定）。tags字段中至少包含env1或deployed中的一个（由should子句和minimum_should_match参数决定）。1 | { |
Easysearch 直接支持 SQL 查询，无需额外安装插件，同时兼容 Elasticsearch 的 SQL 调用方式，还可以直接编写原生 SQL 查询。
以下是一些测试 SQL 语句的示例：
1 | SELECT * FROM my_index; |
Easysearch 提供了对直接使用 SQL 查询的支持。以下是如何在 Easysearch 中通过 POST 请求使用 _sql 端点进行查询的示例：
执行 SQL 查询非常简单，只需通过 POST 请求发送 SQL 查询即可。以下是一个示例：
1 | POST /_sql |
你也可以规定返回 JSON 格式：
1 | POST /_sql?format=json |
和 Elasticsearch 一样，Easysearch 允许你通过 POST 请求直接在集群上运行 SQL 查询，并返回查询结果。以下是一些常见的 SQL 查询示例及其对应的 POST 请求：
查询所有文档：
1 | POST /_sql |
限制返回文档数：
1 | POST /_sql |
按字段排序：
1 | POST /_sql |
筛选条件查询：
1 | POST /_sql |
精确值查询：
1 | POST /_sql |
查询空值：
1 | POST /_sql |
查询唯一值：
1 | POST /_sql |
聚合函数查询：
1 | POST /_sql |
分组统计：
1 | POST /_sql |
以下是多表操作的 SQL 语句及其解释：
子查询：
1 | SELECT * FROM table1 t1 WHERE t1.id IN (SELECT id FROM table2) |
这个查询从 table1 中选择所有字段的记录，其中这些记录的 id 在 table2 表中也存在。
内连接：
1 | SELECT * FROM table1 t1 JOIN table2 t2 ON t1.id = t2.id |
这个查询进行内连接，从 table1 和 table2 中选择所有字段的记录，前提是 table1 和 table2 中 id 相等。
左连接：
1 | SELECT * FROM table1 t1 LEFT JOIN table2 t2 ON t1.id = t2.id |
这个查询进行左连接，从 table1 和 table2 中选择所有字段的记录，即使 table2 中没有匹配的记录，也会返回 table1 中的所有记录，未匹配到的部分会用 NULL 填充。
右连接：
1 | SELECT * FROM table1 t1 RIGHT JOIN table2 t2 ON t1.id = t2.id |
这个查询进行右连接，从 table1 和 table2 中选择所有字段的记录，即使 table1 中没有匹配的记录，也会返回 table2 中的所有记录，未匹配到的部分会用 NULL 填充。
假设我们有两个索引 table1 和 table2，对应于 SQL 中的两个表。
**创建索引 table1**：
1 | PUT /table1 |
**创建索引 table2**：
1 | PUT /table2 |
**导入数据到 table1**：
1 | POST /table1/_bulk |
**导入数据到 table2**：
1 | POST /table2/_bulk |
导入数据后，可以使用 SQL 来执行这些查询：
子查询：
1 | POST /_sql |
内连接：
1 | POST /_sql |
左连接：
1 | POST /_sql |
右连接：
1 | POST /_sql |
效果如下：
match 和 match_phrase 是 Easysearch 中用于全文搜索的查询类型，它们在处理文本匹配方面有不同的用途：
match 查询：
match 查询用于对文档进行全文搜索。1 | { |
match_phrase 查询：
match_phrase 查询用于短语搜索。1 | { |
总结来说，match 更灵活，用于一般的关键词搜索，而 match_phrase 则用于需要精确匹配短语的搜索。
我们先造一些数据，然后使用 SQL 来进行全文检索。
批量导入数据：
1 | POST /table3/_bulk |
执行全文检索的 SQL 查询：
1 | SELECT * FROM table3; |
随着数据量的不断增加，高效的数据搜索和分析变得尤为重要。Elasticsearch 以其强大的全文搜索能力和灵活的数据处理能力成为行业标准。Easysearch 作为 Elasticsearch 的优化版本，不仅继承了其强大的功能，还在性能和安全性上做了进一步的提升，为企业提供了一个高效、稳定且易于迁移的搜索引擎解决方案。通过深入了解这些技术和实践其应用，开发者和企业能够更好地利用这些工具来应对现代数据挑战，推动业务的持续发展和创新。
]]>INFINI Console 是一个功能强大的数据管理和分析平台，其仪表盘页面提供了直观简洁的界面，使用户能够快速了解系统状态并进行管理操作。本文将详细介绍仪表盘页面的各项功能。
仪表盘顶部显示系统的实时告警、通知和待办事项的数量，当前数据显示：
在仪表盘的中心区域，用户可以看到几项关键的系统概览信息：
仪表盘页面还提供了几个常用操作的快速入口，方便用户迅速访问常用功能：
仪表盘右侧显示了集群的动态信息，包括最近的操作日志。例如：
集群管理页面主要分为几个部分：顶部的功能选项卡、中部的集群列表、以及右侧的筛选和排序选项。
页面顶部的功能选项卡包括以下几项：
集群列表展示了每个集群的详细信息，包括：
页面右侧提供了丰富的筛选和排序选项，可以根据以下条件筛选和排序集群：
接下来分别介绍节点、索引和主机层面的信息，这些监控指标与集群层面大同小异。
节点监控
索引监控
主机监控
包括了常规的 CPU、内存、磁盘、网络的监控。
监控报表页面提供了对集群运行状况的详细监控和分析功能。用户可以选择最近 15 分钟、1 小时、24 小时等不同时间范围查看数据，并手动点击刷新按钮更新数据，以获取最新的监控信息。
显示当前集群的基本状态，包括：
监控报表页面还提供了多个性能指标的图表，包括：
点击“Advance”可以查看更多监控指标：
包括 CPU、负载、JVM 内存、剩余使用空间及磁盘空间、集群启动时间和索引读写情况。
包括集群内索引的数量、状态、主分片和副本分片数量、文档条数和占用空间。
提供集群中各类事件和活动的详细记录和监控功能。
别名管理页面提供了对索引别名的管理功能，使用户可以方便地管理和配置 Elasticsearch/EasySearch 的索引别名。
可以通过 DSL 创建别名。例如，创建一个名为 my_index_alias 的别名指向 `my_index
`：
1 | POST /_aliases |
删除一个别名同样可以通过 REST API 实现：
1 | POST /_aliases |
索引轮换是一种常用的索引管理策略，特别适用于日志和时间序列数据的场景。通过索引轮换，用户可以在索引达到一定条件（如大小或文档数量）时，创建一个新的索引来继续存储数据，而旧的索引可以继续用于查询。
current_write_index。创建初始索引并设置写别名：
1 | PUT /my_index-000001 |
使用 /_rollover API 定义轮换条件并执行轮换：
1 | POST /current_write_index/_rollover |
通过这种方式，查询操作可以透明地访问所有历史数据，而写操作总是指向最新的索引。
在 INFINI Console 中提供了可视化创建索引及别名的方式。页面右上角提供了新建按钮，用户可以通过点击该按钮创建新的索引别名，填写别名名称、关联索引、索引路由、搜索路由和过滤查询等配置。
展示了多个关键指标的监控图表，包括：
我们还能够看到更多指标：
在数据探索里，可以根据时间、字段等条件对索引或者视图下的数据进行搜索查询和分析，类似 Kibana 的 Discover。
这里可以看到集群的警报，目前集群运行良好，没有任何警报。
内部会预设一些警报规则，如下：
点进去一个请求，比如磁盘的警告，可以针对不同的使用量设置不同的警告级别和通知。
这里针对警报设置警报，可以看到现在支持很多平台，Discord、飞书、邮件、微信、Slack 以及钉钉。
点击进去可以查看，对于社交软件而言，其实是使用 Webhook 进行通知，除此之外也支持配置邮件服务器和自定义的 Webhook 进行通知。
Console 的开发工具相当于 Kibana DevTool 的升级版，使用上基本没有大的区别，除了支持 DSL 之外，还支持多集群 Tab 切换、常用命令快速 Load、SQL 查询等。
可以看到连接这三个集群的凭证管理，目前都是有效的。
可以添加用户以及修改 console 管理界面的密码。目前设置了 admin 账号。
追踪对集群的操作，捕获查看集群监控信息以及集群索引的操作。
INFINI Console 的仪表盘页面集成了系统的关键信息和快捷操作入口，使用户可以高效地管理和监控系统。通过详细的概览信息、实时的告警通知、快速的功能入口和动态日志，用户能够对系统的运行状态一目了然，并快速响应各种管理需求。这个设计不仅提升了用户的工作效率，还确保了系统的安全和稳定运行。
INFINI Console 的集群管理页面提供了对系统集群的全面监控和管理功能。通过详细的集群信息展示、便捷的功能选项卡切换以及丰富的筛选和排序功能，用户可以高效地管理和监控系统中的集群状态。这不仅提升了运维效率，还确保了系统的稳定运行和高效管理。
INFINI Console 的节点管理页面提供了对集群节点的全面监控和管理功能。通过详细的节点信息展示、便捷的功能选项卡切换以及丰富的筛选和搜索功能，用户可以高效地管理和监控系统中的节点状态，从而提升运维效率，确保系统的稳定运行和高效管理。
INFINI Console 的监控报表页面提供了对集群运行状况的全面监控和分析功能。通过详细的概览信息和多个性能指标图表，用户可以高效地监控和管理集群的运行状态。这不仅提升了系统运维效率，还确保了集群的稳定运行和高效管理。
通过这些功能，INFINI Console 为用户提供了全面的系统管理工具，帮助他们高效地应对各种运维挑战，确保系统的高效、安全、稳定运行。
]]>1 | echo "alias aa='your-cmd'" >> ~/.zshrc |
Easysearch 支持原生 Elasticsearch 的 DSL 查询语法，确保原业务代码无需调整即可无缝迁移。同时，极限科技还支持 SQL 查询，为熟悉 SQL 的开发人员提供更加便捷的数据分析方式。此外，Easysearch 兼容 Elasticsearch 的 SDK 和现有索引存储格式，支持冷热架构和索引生命周期管理，确保用户能够轻松实现数据的无缝衔接。
无论是 Linux 还是 mac 都是这个一键脚本
1 | curl -sSL http://get.infini.cloud | bash -s -- -p easysearch |
同时也提供了二进制的安装包：
如果不想整理 JAVA 环境问题，还可以使用这个
https://release.infinilabs.com/easysearch/stable/bundle/
官方提供了 Docker Compose 样例，包括三个服务：easysearch-node1、easysearch-node2 和 console。以下是详细说明：
版本控制：
version: '3' 表示使用 Docker Compose 文件的第 3 版格式。服务定义：
easysearch-node1 和 easysearch-node2：
infinilabs/easysearch:latest来组成双节点的集群。602:602。ES_JAVA_OPTS 环境变量以配置 Java 虚拟机的内存。ulimits 选项配置了内存锁定和文件描述符的限制，以提升性能。esnet 的自定义网络中。console：
infinilabs/console:1.26.0-1552（该镜像没有 latest，需要手动把 latest 更改位特定的版本号）。links 功能链接到 easysearch-node1 和 easysearch-node2，简化容器之间的通信。TZ 为 Asia/Shanghai。网络配置：
esnet 网络使用 bridge 驱动，提供一个隔离的网络环境，配置了特定的子网 172.24.0.0/16，以确保服务之间的网络通信。1 | version: '3' |
尽管在这里官方提供了详细的命令，完全可以使用这个 docker-compose up 来进行替代。其他的脚本解释如下：
init.sh
1 |
|
reset.sh
1 |
|
start.sh
1 |
|
stop.sh
1 |
|
在我的电脑中，可以看到成功启动的容器。
https://infinilabs.cn/docs/latest/easysearch/getting-started/install/docker-compose/
设置集群连接参数，比如域名端口，用户名密码。
初始化，这里会新建索引，写一些 sample 数据。
设置后台管理的密码，后期使用这个登录控制台。
检查配置，完成集群关联。
这个是后台管理界面，除了用户名密码之外，也支持单点登录：
跨引擎、跨版本、跨集群 独一份！
使用自带的面板进行查看节点数量：
同时也支持 REST 风格的 API 来进行查询。
接下来来使用 Console 连接 Amazon 的 OpenSearch：
同样是输入集群的 URL，用户名和密码。
然后可以拿到集群的信息，比如地址，版本号，集群状态，节点数量。
最后看到连接成功的信息。
我们可以在集群管理中看到 EasySearch 的集群和我们刚刚添加的 OpenSearch 集群。
是否开源？目前还没有开放源代码。
]]>同事说，没有到过外滩就等于没有到过上海，所以我特地在外滩周围订了酒店，然后在黄埔的大都市，我尽情的游玩。计划里有外滩，豫园，城隍庙，还有人民广场，大世界，然后再这一圈 xxx。
就能让我骑着小黄车悠哉悠哉的去看夜晚慢慢变黑，虽然地铁也很近，但是不喜欢那种，但是喜欢那种夜幕悄悄降临的感觉，嗯，对于上班，对上班族最。最残忍的事就是早上踏着踏着日光，或者日光没出来的时候就要出发，那晚上迎接你的就是一片黑暗，你偶尔有。街上的霓虹灯，但就不足以照亮街边的路。
要骑车，这次实实在在栽了一个跟头，在望京的时候，我经常行行在一条笔直的马路上放开了双手去骑行，靠着自然的平衡去穿过一条又一条的街道。为什么说上海栽了一个跟头呢？这是一个实实在在的跟头。平地摔了，嗯，人行斑马线的油漆太重，而且但是在单手去查的导航，所以导致。直接重心不稳，整个人飞，整个人飞了出去，不敢想象当时后面的人是怎么样一个想法。
一般来讲，这种事情都会有一个预兆，比如说后面的事情不顺，但不幸中的万幸就是也就只有膝盖擦破了皮。在行驶到外滩的中途，刚好有一家药店，我可以去买一些消毒器械，简单简单处理过之后，我就到外滩来散步。
当然这两天总会遇到一些管制，比如你世博附近演唱会散场，人流拥挤导致这一带几乎封路，对于地铁站安安检也是无能为力，直接直接放弃，崩溃，直接崩溃，放弃我今天。外滩的周边是不是不允许驶入共享单车的，驶入或者是停放共享单车的，嗯。
这就和你知道长安街相似，长安街禁止在在进故宫一带，长安街只有自行车才能使用，包括带助力的。不带，不带助力的自行车才能驶入，包括电动车都是禁止进入的，所以。在去年的深秋，我才能从百子湾一路骑到石景山，这是我觉得长安街带给我的意义。那么对于外滩呢，嗯，简单的来讲就像是一条街。你沿着黄浦江上的一条街，对面是和陆家嘴这种都市中心不太相望，嗯，在这里我们就可以看到这座城市的地标。
我不知道对于在城市的地位，这两者是否等同，但是可以肯定的是，这里人潮拥挤，确实是一个不得不来的地方。
从上北京到上海，几乎没有什么不习惯的地方，严格上来说是在北京这些方面都被磨合的很好，但不同的地方就是。这里的外国人会多一些，随处可见老外在拍照，在等，等着等着这边的红绿灯。对不对也可以。
外滩当然也不例外，嗯，有来有的外国人也有，也有一对，也有有一些情侣。嗯，可能对于外滩相当于迪士尼来说，确实不是一个适合分手的圣地。
江上的渡轮来来回回的回顾着，似乎一些是为了品牌，另一方面就是为了让为了游客去拍出更加质量，更加有质量的照片。你自拍的时候还是也试着一个人旅游去拍照，但往往总不尽如人意，比如距离感。我没有去拍照，不少，有个有个孩子要，要我帮他去拍照，然后，然后。他还很很乖巧的帮我，帮我先拍了几张。
大概是出于长期被骗的一个新人的我下意识下意识去说，或者是会不会把我的手机带走这样的，但看着对方。看着像一个没有步入社会的大学生，而且是为了演唱会来到这里，后来也就加了微信，他给我传，还顺便赠送了我刚刚出片的照片。刚刚出炉的风景照，这得再次吐槽一下，苹果的像素太难了，安卓一张 16 兆，你苹果呢？
嗯，大概是旅游高峰，而且又是日暮，大家都会堆在入口的地方，但。等回来的时候，可能由于这一片，嗯，一个小时就逛完了，然后等等出来的时候就可以。这人是少了很多，这里看高手大山。
自从离了渤海江畔，到大城市打拼，还真的没有，今年还真没有吹过海，无论是海风还是江风，几乎都没有吹过这样。明天不会感冒，是吧？
转了一圈，又从外滩出来啊，一波又一波的人流，我一个个企图找到一个吃饭的地方，夜晚八点。嗯
来的时候开着导航，在小小巷子里左拐右拐，回去的时候逆着人流走一条最长的街道，然后。在这夜里的八点，你在上海最正宗的小龙虾。
意外的是连接就是和平饭店，嗯，前面有一堆的小吃，今晚只是过来逛逛和平饭店，改天去吃。
]]>
到手是这样的
画质确实很清晰
“买前生产力，买后爱奇艺”。吃灰了好久还是决定利用起来。现在的定位感觉还是视频剪辑，甚至还不能写代码，所以一些重量级别的事情只好远程连接 windows。
这个是外接显示器的效果，距离 M1 可以外接显示已经好几年了，但是 ipad 锁屏之后外接显示器也会黑屏的这个问题还是没有修复，最后只能把 ipad 的亮度调到最低。
这个是 RDP 连接 Windows 的效果，除了 RDP logo 之外也看不出来其他的东西，然后就可以使用妙控键盘来控制了。
由于合上盖子会导致自动锁屏，所以需要在设置里关闭自动锁定。（本来为了省电设计的功能，到这里就变成了负优化）
这个是合上盖子的效果。
合上盖子 RDP 的效果：
已经只用 MacOS 当主力系统已经很多年了，就让 Windows 活在虚拟机里吧。
]]>物质激励会减弱内在动机，降低绩效；鼓励不道德行为，减少创造力；助长短视思维。
[toc]
O：objectives 目标
KR：key result 关键结果
针对O有KR1，KR2，这个其实类似于里程碑，
| O | KR | 信心指数（1-10） | 备注 |
|---|---|---|---|
| KR1 | |||
| KR2 | |||
| KR2 |
每日站会 -> 周会 -> 月度会议 -> 季度会议 -> 年度
S：Specific 具体的
M：measurable 可衡量的
A：attainable 可实现的
R：Relevant 相关的
T：time-bound 有时限的
帕雷托原则，也可称为二八法则，由意大利经济学家帕雷托提出，意思是让20%的投入产生80%的效益
我们在每天的工作中，总会有精力充沛的时候，也会有大脑疲劳不堪的时候。因此我们要把握一天中精力最充沛的时间去集中精力做重要的事情。在疲惫时，我们则可以停下重要的工作，去做一些琐碎的事情，比如处理邮件等。
“吃青蛙”定律来自博恩·崔西的《吃掉那只青蛙》。
“青蛙”是指最艰巨、最重要的任务。坚持三个原则：
每天早上做最难的那件事，那么，一天之内就没有比这更糟糕的事情了；
面对两件重要的事，要优先做更重要的那一件；
对于重要的事，要立即行动，说做就做，否则考虑得再周全而不行动也无济于事。
时间管理小贴士
| 1.拒绝拖延症 | 2.赢得时间 |
|---|---|
| 把工作写在纸上思考 | 建立工作时段，集中处理重要任务或同类任务（批量处理，缩小切换的时间） |
| 开工前准备好所有材料 | 设立拒绝打扰时间（保持专注） |
| 从小事做起 | 重要的事情拥有优先权（要事第一） |
| 将任务分成若干环节，分别进行处理 | 尽可能做那些确实关键的工作 |
| 抑制完美主义 | 学会授权，对于烦琐的服务性工作可以借助他人之手（授权外包） |
| 保持快节奏 | 任务分解，由大到小，由复杂到简单（任务分解） |
| 给每一项任务规定完成期限（DDL，没有期限的会一直拖着） | |
| 重点任务，尽早完成 (吃掉那只青蛙) | |
| 根据自己工作效率或者注意力的高低波动，规划做事顺序（能量高峰） |
在家办公的时候，我们制定OKR要注意：
（1）周期可以更短，1个月或者两个月为一个周期，甚至一周，加快节奏，提升产出；
（2）要与上级及关联者沟通，达成一致。
遵循以下5W1H法则：
何人（Who）：
何时（When）：
何事（What）：
何地（Where）：
为何（Why）：
如何（How）：
● 具体的任务：要做什么？
● 任务的产出：如何判断完成了任务？
● 任务的完成时间：什么时候完成？
● 每个任务，完成的时间不超过1天。
● 每个任务，都应有完成标志。
● 任务的完成信息，能够共享和同步。
● To Do：本周计划要完成的任务项。
● Doing：今天将要做的任务项。
● Done：本周已经完成的任务项。
每次深度工作可以设定在45分钟到1.5小时之间。
根据注意力恢复理论，我们的注意力是有限的，只能在一段有限的时间内专注于一项任务，直到它变得让人筋疲力尽。
至于一项任务是否属于深度工作，可以参考以下问题：
● 该任务是否需要集中注意力？
● 任务需要有专门的知识技能吗？
● 任务很难重复吗？
● 该任务会创造新的价值吗？
保持不间断的专注，你需要创造一个无干扰的环境。这意味着要屏蔽无关的和破坏性的打扰——聊天信息、电子邮件、会议、电话、社交媒体及其他杂音。非常需要注意的一点是，要与你的团队和上级达成一致：允许你不及时回复消息。
由于这个原因，许多人强制执行严格的“隔离措施”：
● 将手机设置为“免打扰”模式；
● 将邮箱设置为自动回复消息；
● 将“深度工作”时间分享给同事。
每周回顾：花时间反思过去一周进展顺利和失败的原因，并计划下一周的工作。
这是检视目标，并确保自己每天所做的工作能够帮助自己实现目标的机会
在回顾的时候，我们可以参考以下问题清单：
● 我本周总体感觉如何？
● 是什么让我在本周达到目标？
● 有什么事情阻止我本周实现目标？
● 我本周采取了哪些行动来推动我实现长期目标？
● 下周我该如何改善？
● 下周我该怎么办，以使我实现长期目标？
营造环境、明确目标、深度工作和每周回顾，这是使在家工作更高效的四步法。
但是，至关重要的是：寻找初心。
初心，是指自己感兴趣的事，能发挥自己优势的事，可以实现自己价值的事。
拥有初心，你就具备最大能量，就会取得更多成果。”
时间表参考：
| 上午时间 | 要做的事情 | 备注 | 其他 |
|---|---|---|---|
| 6:00 - 7: 00 | 晨间流程 | 先洗漱收拾屋子（30min），然后冥想，做导引（30min）， | |
| 7:00 - 8:00 | 吃早餐 | 上个流程把该下锅的都下锅 | |
| 8:00 - 9:30 | 深度工作 | 内容为： | |
| … | |||
| 12:00 - 13:00 | 午饭 | ||
| … | |||
| … | |||
| 16:30 - 17:00 | 结束工作 | 需要复盘然后规划下一天 |
自我激励:
● 成功之后奖励自己吃冰激凌
● 每天早上起来对着镜子说：我是最棒的
● 回想自己的巅峰时刻
● 告诉好朋友自己的想法
● 先开始一小步
● 记住：完成胜于完美
]]>MacOS 安装的命令如下：
使用该命令会自动拉取源码包并且自动编译，然后使用 sunshine 命令启动：
1 | brew tap LizardByte/homebrew |
这个服务会启动在 47990 端口，进入网页是这个样子
客户端是使用 moonlight，可以在 app store 直接下载
点击 Add Host Manully，填入服务端的 ip。
然后会提示提示配对，这里给了一串 PIN 码，需要填写到服务端的 WEB 中
然后把上一步 moonlight 的 PIN 写到这里
然后对于 MacOS 来说，需要给到终端录屏和辅助功能的权限。
然后就可以开心的玩了～
这里记录一次电容充电的记录,尽管理论上电容键盘是无限寿命,但是也遇到了按键失灵的问题,客服解释说是缺电需要充电,同时提供了对应的驱动软件,大概过程就是插上电脑,然后用检验工具按下任意键就好了.印象里就充了一次电然后好几年都没问题.特此记录下来
因为 PicGo 没有签名，所以会被 macOS 的安全检查所拦下。
信任开发者，会要求输入密码:
1 | sudo spctl --master-disable |
然后放行 PicGo :
1 | xattr -cr /Applications/PicGo.app |
然后就能正常打开。
]]>首先在 apple 日历部分添加 outlook 账户，这样就可以配置完 apple 日历和 outlook 的双向同步，在 MacOS/IOS 上安装 outlook 客户端，然后 windows 只需要使用默认的邮件客户端即可。
1 | graph LR |
从下图可以看到日历分为 outlook 和 icloud 的部分，我们把后续的日程添加到 Outlook 部分就好。另外注意的是，outlook 的默认日历就叫做“日历”，不能修改名字也不能删除。
同时我也在 apple 上安装了 sorted3，只有日程会被上边的流程同步，任务只能用软件自带的 icloud 同步（apple 设备），这样就满足了在 window 和 apple 随时查看和编辑的功能了，sorted3 中也可以选择需要同步的日历。
对于批量的日程，那么需要用到 ICS 文件，实测 iphone 的微信不能唤起 apple 的日历，所以采取了发邮件的办法，这里用到的是 apple 的邮件客户端，倒入 outlook 会有些许同步的问题，就不再继续研究了。手机的 Apple 日历倒入之后，全平台很快就可以进行同步了。
这样无论是 apple 日历，outlook 还是 sorted3，只要一个软件添加日程，剩下的平台都会同步。
最近终于把软路由搞定，群晖上也顺利安装好了 Docker，于是立马安排上迟到了好几年的 Home Assistant（简称 HA）。这篇文章就分享一下如何用 HA 把米家设备接入 Apple 的 HomeKit，真正实现“苹果家庭全自动”的梦想！
先直接上命令。建议使用 host 网络模式，不然后面 iPhone 添加 HomeKit 的时候经常找不到设备。
1 | sudo docker run -d --name="home-assistants" --net=host homeassistant/home-assistant |
小提示：我图省事没做目录映射，但大家正式部署还是建议把
config映射出来，便于备份和迁移。
启动完成后，默认监听在 8123 端口。浏览器访问 http://群晖IP:8123 即可进入 HA 初始界面。
第一次访问会提示你创建账户。
接着可以选择你的地理位置，后面用于推送天气等信息。
参考的是小米官方的 Home Assistant 插件项目：
🔗 项目地址：https://github.com/XiaoMi/ha_xiaomi_home
先进入 HA 容器内部，然后安装插件。
1 | cd config |
完成后重启 HA 容器，重新登录到 UI 界面。
点击左下角“设置” → “设备与服务”，进入集成页面：
点击“添加集成”，选择 Xiaomi Home：
会先看到免责声明，点继续。
插件采用 OAuth 登录小米账号，这一步会打开小米官方的登录授权页面。
登录成功后返回回调地址：
⚠️ 注意：默认回调地址是
http://homeassistant.local，很多时候解析不了。可以手动把浏览器地址栏改成http://你的HA局域网IP:8123，再回车，就能完成回调流程。
成功登录后会同步你米家账号下所有的设备：
数量感人！
进入“设置” → “设备与服务”，右下角点击“添加集成”，选择 HomeKit：
接着选择 HomeKit Bridge：
添加完成后左侧会出现一个 HomeKit 的二维码，使用 iPhone 上的“家庭”App 扫码配对即可。
添加过程中，如果出现以下提示，说明网络设置有问题，大概率是 HomeKit 无法找到设备。
如果 iPhone 迟迟找不到 Home Assistant 设备，务必检查网络配置：
host 网络模式；
左下角点击头像，开启高级：
没开高级的话是这样的：
终于圆梦！所有米家设备都顺利接入了 HomeKit，iPhone 上可以直接语音控制开灯、调温度，真正体验到苹果生态下的丝滑体验。
从部署 HA 到米家设备接入，再到 HomeKit 配对，中间有点小坑，但整体体验还是很不错的。如果你也想让米家秒变 HomeKit 原生设备，不妨试试这个方法。让智能家居真正融入 iOS 生态，丝滑又稳定！
]]>
接下来就是把手机/手环放在机器进行写入
添加成功
NFC-PRO 至尊双频版操作说明
读写卡操作视频:
https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/409421501065.mp4
加密卡手机手环模拟操作视频:
https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/409017352153.mp4
于是在 ChatGPT 上询问了相关事宜,大概意思就是一个把雷电设备虚拟成一张网卡,然后设置一个单独的网络通道,两台机器使用 IP 地址进行通讯,知乎上也有成功的雷电 3 案例,只是他们 WebDav 的速度是 600MB/S
而我的是雷电 4 也是这个结果,只是在 NUC12 识别时候总是不能满速识别.
咨询客服之后也没有得到满意的结果,不久前 intel 吧 nuc 业务线给华硕了,结果售后只是给排查方向,看 BIOS 有没有打开雷电开关之类的,或者就是等待十天半个月的返厂检测.
webdav:
window 下显示
20G 的虚拟网卡,在 linux 下也是如此
设备管理器显示 USB4 而不是雷电 4
直连 MBP 两个雷电口:
popos 和 MBP 使用 iperf3 对打:
MacOS: 雷电 4 的线+40G 硬盘盒
win 测速
门前的松树又多新雪，一夜之间多了些许北国的味道，鹅毛大雪飘散着，伸出手凉凉的就化了。
北京的冬天很温和，对于东北人来说像深秋，静静的飘雪中撑一把轻伞，就能轻松制造韩剧男女主角的邂逅，北京的人是不是没体会过风刀霜剑？这的雪是留不住的，在气温回暖以及汽车尾气的破坏中，渐渐的融化成水，再蒸发成空气。不喜欢雪的人，是觉得雪堆融化之后道路泥泞，车辆难行，甚至气温来一个急转弯，把这雪水变成冰沙，甚至再光滑一些，这总会影响行人的匆匆。
每一片飘落的雪花，好似这芸芸众生，降生，飘零，陨落以及消亡。一片一片的雪花组成了洁白的雪地，雪地上留下了行人的脚印，有三两好友在讨论，有奔波的快递员外卖骑手，窗下还有小孩子在玩雪，老人在哄孩子，小男孩在团雪球，小女孩在一边看着，穿过街道，已经是光洁的柏油马路，这是雪冢。
无人的雪，踏上有吱吱的声音，光洁的雪总是能给人遐想，好似可以根据心思任意雕琢，又或者因为不是最佳路径从而无人踏足，而不远的一旁布满了行人的脚印，我却刻意绕开。夏日的大排档被闲置在这里，棚子上积满了厚厚的雪，伸出手来攒个小雪球，等着越滚越大。
等待手机升级的功夫，顶了一头的芦花。
这个最后基本上可以确认是一个兼容性问题，测试完成发现， 开启兼容模式的 Opensearch+filebeat 的组合， filebeat 还是会不定期重启。
需求是，使用 ES + filebeat 模式在收集日志。
使用 Supervisor 作为容器的主进程管理工具，启动后分别运行 应用（这里用 nginx 代替） + filebeat
现在想要用 ECS Fargate， 然后依旧还是这个模式， 尽可能新的变动之前的架构， ES 替换成 OpenSearch。
按照这个路数测试。
版本：
OpenSearch 2.11 (latest)
OpenSearch_2_11_R20231113-P1 (latest)
Availability Zone(s)
1-AZ without standby
创建 dockerfile 的部分， 比较难的是 ， 需要找到合适的 filebeat 版本
参考页面: Agents and ingestion tools
其他的步骤就下载安装就可以.
1 | # 使用官方Nginx作为基础镜像 |
需要准备的配置文件一共 3 个：
1 | cat ./supervisord.conf |
filebeat.yml filebeat 的配置文件。 这配置文件 GPT 会直接写出一个可以用 output.opensearch:， 其实还是不能的， 只能使用原本的配置文件。 (也许是我选择的 filebeats 版本不正确, 所以不行吧
filebeat 本身是 es 序列里面的产品， 不支持 opensearch 也合理， 如果写成 opensearch 会找不到 output 的定义， 也说明并不支持这个字段。
2023-12-14T12:03:12.560Z INFO [publisher_pipeline_output] pipeline/output.go:145 Attempting to reconnect to backoff(elasticsearch(https://vpc-ecs-nginx-opensearch-qt7m5rmhddggkiuapyybcmz5oe.cn-north-1.es.amazonaws.com.cn:443)) with 7 reconnect attempt(s)
1 | ```shell |
xpack 报错的日志大概是这样的：
2023-12-14T12:03:12.560Z ERROR [publisher_pipeline_output] pipeline/output.go:154 Failed to connect to backoff(elasticsearch(https://vpc-ecs-nginx-opensearch-qt7m5rmhddggkiuapyybcmz5oe.cn-north-1.es.amazonaws.com.cn:443)): Connection marked as failed because the onConnect callback failed: request checking for ILM availability failed: 401 Unauthorized: {“Message”:”Your request: ‘/_xpack’ is not allowed.”}
2023-12-14T12:03:12.560Z INFO [publisher_pipeline_output] pipeline/output.go:145 Attempting to reconnect to backoff(elasticsearch(https://vpc-ecs-nginx-opensearch-qt7m5rmhddggkiuapyybcmz5oe.cn-north-1.es.amazonaws.com.cn:443)) with 7 reconnect attempt(s)
1 | access_log /var/log/access.log main; |
由于 baseimage 用的是 nginx 的， 所以 nginx 的日志输出会软链接到/dev/stdout, filebeat 不收软链接的文件, 开了 DEBUG 会看到跳过这个文件的日志.
接下来就可以 Build 镜像然后进行测试了。
1 | dive build -t reg.liarlee.site/library/superv-nginx:v31 . |
运行启动之后可以看到输出的日志是：
1 | 2023-12-14 14:03:31,093 INFO success: filebeat entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) |
然后查看 Opensearch 创建了默认 index， 名称是filebeat-7.12.1-2023.12.14
所谓爱屋及乌，经常有一种爱她就要包容她的一切的言论。那么反过来也是一样的，如果是在几经磨合之后仍然不能付诸真心，或者经历了无数次想去改变对方，再或者对现状无能为力只能默默叹气的时候。举个例子，对妹夫看不顺眼的时候，但凡在他们孩子身上看到任何相似之处，也都会有种莫名的不喜欢，甚至是把情绪转移过来。
周围的人大概有这样几种状态，单身未婚，同居未婚，已婚未育，已婚养娃。
单身未婚要么没有遇到正缘，要么是感情上面的独行者，常常被他人贴上活在自己世界，适合一个人的标签。他们也许渴望一场轰轰烈烈的爱情，但从不轻易涉足。
同居未婚，有些人打算长期维持这样的状态，彼此间相对比较独立，而且大多是丁克主义，双方也有稳定的收入，还不用在乎双方的亲戚闲言碎语以及社会舆论，那么在矛盾冷战时候也会发出是不是分手的质疑？
还有很大一部分人，不管条件如何，总归是先住在一起，然后再慢慢磨合，他们可能是大学生，也可能才刚刚步入社会，经常说出的话是顺应自己内心的想法，而且大多讲究顺理成章顺其自然，一旦有了夫妻之实，在分开之后另寻新欢很难说不是二婚。
当然也有些是真爱，本就打算结婚，然后住在一起，互相之间总会有个照应。然后一起走过磨合，订婚，再结婚的过程，这也不失为一段佳话，既加深了羁绊，也创造了彼此间的记忆，甚至哪怕新婚燕尔，甚至也能用老夫老妻这样的话语来调侃了。
养娃的人是最累了，十月怀胎，甚至民间还有一孕傻三年的说法。前几种情况相比，只有这有母性的光辉。而且常常被不孝有三，无后为大的观念所左右。不管是出于传宗接代还是其他的目的，在这的过程中，总会不自觉得强加上去自己的想法，甚至要求他做的更好抑或是不能落后于人，抑或者彻底沦为炫耀的资本。但对于家庭和事业兼顾的人来说，这往往很难两全，总会给孩子留下一些原生家庭的不安与不适感，并且常常对此无能为力。
几十年后的养老院，还是那样大的院子，周围还是同龄的人，仍然会把人分门别类，依旧听着要那个人的发号施令，江湖依旧是那个江湖。但，最近的新闻总是看的心惊胆寒，现代文明带来的身心不适已经极大的缩短了人的寿命，谁又能保证真的能活到那一天呢？幼年时盼望有人披着晚霞，踏着黄昏带你走出这桎梏，耄耋之年为何又作茧自缚，穿过着一阵阵的喧嚣，却只能看他人天伦。
对于不婚不育的人，我们一方面要感谢他们为人口减少作出的贡献，另一方面也会出于自己小小的私心，想要伴随生命从小到大的成长，即使无法告知他人生的意义，即使在他18岁的时候会也发出安德烈一样的感慨。谁说不能效仿古人，一门七进士，父子三探花呢？
]]>
这边都是写字楼，所以工作日会针对上班的人有优惠，一般不包括周五，因为要放假了大家都 high 起来了，人多的没有位置。
可以看到从望京一路吃到酒仙桥～
PS 北京吃的汇总：
speedtest： https://api-v3.speedtest.cn/ip
1 | { |
IP.cn: https://ip.cn/api/index?type=0
1 | { |
IP API: http://ip-api.com/json/
1 | { |
https://checkip.amazonaws.com/
123.113.111.178
加了宽带师傅 B 微信，几天没有结果，经得知属于联通网络，遂工信部投诉，第二天联通打电话，告知他们 IP.cn 和 speedest 都显示是联通的 IP。联通师傅 A 一直在重复不是联通的网，然后安利办理宽带。询问是不是有二级运营商或者其他方式走联通的主线缆，师傅 A 还是在重复不是联通的网，而且谈话提到师傅 B 又还是岔开话题显然知道里面的猫腻，又开始重复不是联通的网让再办一条。无奈只能赶他出去了。
接线的也是人才，一根 8 芯的线硬生生给拆成了 4 根接 WAN，4 根接 LAN，网线的一头同时接 WAN 口和 LAN 口。
从 4-80M 不等实现了全屋 200M 宽带覆盖，DHCP 看到连接成功。
traceroute 结果如下，上边还是有个交换机，好像还是给包了一层，中间商做的 PPPoe。
在附近找了一个门店挺大的兰州牛肉面，面中规中矩，就是再来到这片区域，距离上一次，已过廿余年。
除了逛商场,还要写吐槽。
性价比很高
点餐服务员完全听不到,最后连着叫了三次,慢吞吞的回我,点的第一个菜就对不起没有.也没说明白原因.在我点餐过程中倒是很原因和别人聊天,有被冒犯…(菜品还行吧,性价比很不错,锅包肉带着 120 分期待来了,最后只能给到 95 吧,上来的时候外壳发软,不脆,觉得是锅包肉大忌,然后就是调的汁没有挂匀,萝卜啥的少的可怜,有的感觉在吃炸酥肉)。优点是量大味道纯,肉也多,不是靠面糊的技巧来少放肉的那种.对于餐饮的平时,大家都讲当地及格线是北京的天花板.
感觉不缺游客,几乎没什么好态度
Part1:大疆 (商场)
我:pocket3 现在还断货么
对方:没货
我;是不是今年就不会出 pocket4 了
对方:我不知道
我:这个无人机是新品吗
对方:不是
我:这个支持编程么
对方:不支持
不看无人机了,看相机
问:5pro 和 pocket3,拍 vlog 哪个好一点
答:看你场景
我:我知道我还问你???????
而且在店里走到哪里被跟在哪里,很不舒服
Part2:小米店(商场)
不推销手里哪里好,就说买吧买吧 换个手机
我:我是 Apple 全家桶,有些功能没发用安卓
对方:airdrop 能,只有小米原生支持
我:还有随航和接力呢
对方:airdrop 能,只有小米原生支持
用他自己手机演示,当场翻车,一个文件都过不去
然后看到 iphone 上装了一个小米生态的助手…
问:这不是还需要额外安装软件么,也有很多三方软件能办到啊
答:三方如何如何…
(内心 OS):给你讲开源你也不懂啊….
拿起一台小米手机,解锁屏幕两行 ssl 的 Exception 报错
对方:这个是商场的网不好导致的
………
Part3:秋林-里道斯总店
由于刚去了秋林感觉可能被忽悠了,然后问一下这个是不是总店
只得到对方的一句,这不写着呢么
又问鲜酿的格瓦斯的规格,又被没好气的,指了个小牌子这写着呢
然后给接饮品的时候,把我这个暂停了跟别人聊天,然后聊完继续接,大姐你这单片机中断学的真好…
挺好喝的,打算邮寄点,但是现场接的没有塑封不确定会不会撒,然后问了一句,得到一句含糊不清的话,人走了 再也没见到过她…..
另一个展柜,
问 :秋林和秋林里道斯什么区别呢?
答:两家公司….
我知道人多你们忙,没有态度全是质量……
**Part4:**新一百楼下中央大街
问:怎么买马迭尔冰棍
对方手一指,答:那(nei)边
问:都有啥口味的呢?
对方手换个方向一指,答:那(nei)边.自己看
Part5:中央大街 秋林-里道斯分店
鲜酿的格瓦斯没喝够(18 块的饮料,17.5 的冰镇和气)
到中央大街终于看到分店,到档口准备再卖一瓶,又不确定分店品质
大哥自顾自的把白桦树饮料摆在我面前的台子上,正当我以为他要说,喝点啥的话术的时候,然后他走了…..
我赶紧盯着他的店内包邮的牌子问多少钱包邮啊,,,没好气的回答 100 多….
大哥你这么做有生意么?
想起了之前在北京吃的日料被怼够呛的经历(回去美团找了下评论 倒闭了哈哈哈)
我:帮忙拿双筷子
服务员:等会
我:xxx 菜还没上
服务员:我知(二声)道(拉长音~)
我:有没有哪个位置不吵的
服务员:没有不吵的(斩钉截铁)
差点喷国粹,大哥你东北的吧.
高德导航到秋林食品总店,一个小屋子,还没客厅加上厨房大感觉,屋子里就我一个买货的,询问后不提供试吃,遂买了一根感觉味道不对..发干,而且还有黑点点(以前吃的咋没有),一直在 diss 商委
抓了路人(纯路人,交警,司机) 差不多都是当地人
有的推荐秋林总店,秋林商城,商委
路边的广告大屏幕啥的都是秋林里道斯,跟湖北宣传来菜似的.
秋林商城:地下一层,感觉各种小商贩的聚集地,小超市的感觉吧,毕竟挂着秋林的名头,但是红场看着就发红,经验感觉不靠谱…(自己标了伊雅红场)看介绍是创始人的名字
里道斯国际大厦(秋林里道斯):看人数这下应该对了,排的长队都去买散装然后自付两元打包装,说是流动快新鲜些,正常商品包装的几乎没啥人买,两者价格一样的….
两家都是自己始于 1900.百年老店:口径都是和对方是两家店
商委:炒的太火了,都有肠贩子了,据说需要排队.距离也挺远的,以后有机会再探吧,
上车的时候用 apple watch 记录地图,下车消耗 290 卡…
地铁也很没素质哎,我去哪里排队然后就有人去哪里插到我前面或者是,占用下车区域..换了两三回 还碎碎念
回去的时候在路边等车，不是什么时候看到小情侣在亲亲我我，啊，这不就是现代的雨霖铃吗，总会升起一种莫名的反感，祝天下有情人终将分手吧。自古以来就没有什么非谁不可，饮食男女，人之大欲。在我这里，竟升起从未有过的陌生感。我会在旁边脑补他们吵架到分手，出轨，以及在原生家庭的冲突下意见不合，然后产生冷漠，偏见，以及厌恶。于是失去理智的歇斯底里，但是又不得不为了下一代继续苟延残喘。又仿佛这一切从未发生过。
客车上写到这昏昏睡去, 梦醒来满脑子都是“刘彰暗弱无能.星夜奇袭成都,庞统百拜”, ”主公,张松是我出卖的.刘彰背信弃义,在主公退军路上设伏杀了你军师,主公这下师出有名了吧“
回去复盘这一天的糟糕经历, 再也不想去了.都是说来东北东北虎,我今天甚至都不用买门票.
啊,东北虎果然是形容词
不写了……省城都这样,那其他地方得啥样啊….
]]>又稱紅汞，汞會讓蛋白質凝固沉澱，所以有抑菌的作用，因為對人體組織的傷害較小，曾經廣泛使用於局部皮膚創傷，是預防細菌感染最常用的表皮消毒藥水。
為何當初會拿來作為傷口處理用？大家小時候做生物實驗為了要看清楚細胞或是某些組織，會用染色劑把它們染色方便觀察。紅藥水就是這種作用，紅色顏料嘛！只不過對於細胞來說，染色劑會把細胞毒殺，所以被染過色的細胞，就等於是死了，同樣的道理，細菌本身也是細胞，所以當細菌被染色劑碰到時，也同樣會死亡。古時候醫療沒有很發達，就會使用比較容易取得的染色劑作為傷口殺菌之用。
使用紅藥水除了要擔心會有汞殘留人體外，還會看到很明顯的紅色，造成傷口色素沈澱，會留下疤痕，另外蠶豆症的患者不可以使用。其實紅藥水抑菌作用微弱，治療效果差，現在幾乎沒有在使用了！
主要成分是龍膽紫稀釋溶液，也可以叫結晶紫，聽到結晶紫是不是也勾起大家小時候做實驗的回憶？
用來分辨細菌的革蘭氏染色法裡面有個步驟就是使用結晶紫。因爲它的陽離子能和細菌蛋白質的羧基結合，影響代謝而產生抑菌作用。它能抑制革蘭氏陽性菌，特別是葡萄球菌，對白色念珠菌也有較好的抗菌作用。外用可治療皮膚與粘膜的創傷感染及潰瘍、小面積的燙傷、鵝口瘡等。
不過傷口感染化膿時，不適合使用紫藥水，因爲它有收斂作用，會在傷口表面形成一層痂膜，讓壞死組織中的膿難以排出而向深部擴散，加重感染。紫藥水會使皮膚殘留紫色痕跡，脫色不易，所以對較大面積的傷口，盡量避免使用。而且跟紅藥水一樣，蠶豆症的患者也是不可以使用，否則會引發急性溶血反應。
值得一提的是，因為紫藥水擁有潛在的致癌性，所以現在醫療機構已不用紫藥水來消毒傷口。
成分為Acrinol，也是常見的外用消毒劑。它跟紫藥水一樣，陽離子能和細菌蛋白質的羧基結合，影響代謝而產生抑菌作用。
黃藥水同樣也會染色，不過因為亞洲人皮膚是黃色，加上黃藥水的著色力不比剛剛講的紅藥水和紫藥水強，所以比較容易清除。它的特點是，抗菌效力不受膿血蛋白質影響，所以可以用來治療化膿性傷口。
要注意的是，黃藥水不適用在大於兩手掌面積的傷口或是深部感染傷口。不過因為他的抗菌效果沒有很好，現在也很少使用了。
雖然叫白藥水，但其實不是白色，而是一種透明液體，主要成份是陽離子殺菌劑benzakonium加上局部麻醉劑(Dibucaine Hydrochloride)、血管收縮劑(Naphazoline Hydrochloride)、抗組織胺(Chlorpheniramine Maleate)。應用原理為破壞微生物的細胞膜，除了對抗細菌之外，對真菌也有效。白藥水的特色是它沒有顏色，所以對於擔心傷口被染色劑染色或是衣服被優碘染到顏色的人來說，白藥水算是一個很好的選擇。
白藥水因為添加了局部麻醉劑，所以有止痛的效果，跟擦優碘或是雙氧水比起來，舒服多了。裡面添加的抗組織胺對於減輕局部組織的腫脹及組織液的滲出有不錯的功效，也有止癢的效果。
但是在這邊要提醒各位，如果你的傷口已經傷到了真皮或是皮下組織，建議不要使用白藥水作為傷口處理之用，因為血管收縮劑有傷口收斂的效果，會讓你的傷口更容易產生包覆作用，會讓傷勢惡化在裡面，所以白藥水還是只適合表淺的傷口護理。
又叫過氧化氫水溶液。小時候我賽跑跌倒，手肘磨破皮，傷口看起來髒髒的，回家媽媽拿醫藥箱的雙氧水幫我消毒。真的很痛！我邊看傷口冒泡泡邊哭！媽媽還會說『哭什麼？誰叫你要不小心跌倒？！』這種狠話也只有家人才說得出口。
為什麼我的傷口會冒泡泡？其實雙氧水可以殺菌，是利用它接觸傷口發生氧化反應釋放出氧氣的原理。
雙氧水可以分解血液中的酵素，除去血漬，但其穿透力差，殺菌時效短暫，用在深的傷口，容易造成蛋白質變性，組織壞死，傷口反而不易復原。一般只適合在出血凝塊的表淺傷口處理。目前也不建議將雙氧水直接用作傷口清理之用，因為對皮膚過於刺激，容易傷害到表皮細胞。
優碘呈深褐色，殺菌效果強，可以在20~30秒內殺死病毒、細菌、黴菌、結核菌、原蟲等，為廣效型的殺菌劑，更有預防傷口化膿的功效，而且容易清洗、溫和不刺激，不過塗在傷口在還是會痛啦！優碘是目前使用最廣泛的消毒藥水。優碘會留下黃褐色顏色，容易使皮膚在日曬後形成色斑，頸部以上部分傷口使用時要多加考慮。
不過大家不要誤會，其實優碘並不會造成傷口的色素沉澱，剛剛提到了曬太陽之後會產生色斑，主要是因為陽光照射之後，容易形成紫黑色的固態碘，外觀上會很像色素沉澱所以會引起誤會。
當優碘與傷口組織接觸時，會形成薄膜，然後慢慢釋出碘來達到殺菌效果。但值得注意的一點是，此薄膜通常有點黏黏的，如果傷口較大，大多數人會再覆蓋一層紗布，結果優碘形成的薄膜加上組織液與紗布黏在一起，下次換藥時拆紗布的時候相信很多人都有經驗，絕對痛到你嘴歪眼斜！所以建議塗完優碘後，可以在傷口上蓋上石蠟紗布(如下圖)來降低傷口的沾黏。
今天跟大家分享這麼多消毒藥水，簡單來說，紅、紫、黃藥水目前已經不建議使用，雙氧水如果要用的話，也只適用在第一次消毒傷口，不適合持續使用 ; 頭頸部的表淺傷口可以使用白藥水避免色素沈澱 ; 身體跟四肢的傷口可以考慮使用優碘。
![[Pasted image 20230702120450.png]]
當然要告訴大家很重要的一點，就是雖然居家常備這些藥水，可以處理小型的傷口，非常方便，但如果過了幾天，傷口都沒好轉的跡象，甚至愈來愈紅，愈來愈痛，就要趕快去看皮膚科，畢竟傷口的照顧是一門很大的學問，它還牽涉到用什麼去覆蓋，要不要擦抗生素藥膏，又要擦哪一種抗生慌藥膏，幾天換藥一次，需不要縫合，要不要貼人工皮……等等很多問題，來防止疤痕的形成，這些都不光是擦個藥水就能解決這麼簡單。
]]>有明确目标，加速达成规划
目标不会不变（喜欢做的/擅长的）、
成功不需要天赋（结合自己的技能/技能优劣分类，找出 5 个）
好点子+简单策略，成就=潜能/方向（更高目标+要事优先+其他想法记录暂缓+成功健康共存），其他选择 say no
热情源自于成功，毁于挫败和标签。
创造热情的方法（创造，抢新潮流，整合自己的技能点）
悲观和负面评价只有悲观的结果（习得性无助）、
ABCDE（Adversity 挫折，Belief 信念，Consequence 后果，Disputation 争辩，Energization 获得能量）
不要在乎别人的负面评价。讨好别人只会碌碌无为，屈服于这个时代的暴力。
正面思维加强做事的活力，加速学东西，悲观思维会否定可能性。
正面思维的七个方法：
无法致富的四个观念（钱的罪恶感，对别人的话太敏感，保持现状，不愿意先付出，企业需要三五年后或者 10 年）
复利思维，每天进步一点点
视觉化和肯定
二八定律：20%的努力产生 80%的结果，外包 80%可替代的事情
帕金森定律：有限时间内占用时间会膨胀（限制=高效）任务期限前移一半，尊重承诺，只做少数事情
恢复能量的方法：
精力管理：
操控意志力，给意志力奖励，自我对话激励意志力
记录微小决定待会再做：为大事保存能量
if -then 机制：减少决策损耗的能量
控制工作环境，为工作做铺垫（霍桑效应：被监视的时候更有生产力
5 倍提升法：
每天的能量循环：90/20 间歇：90 分钟深度工作，20 分钟休息，根据自身适当调节
就说咱对于国产的偏见，以及小米路由器频繁抽风挂后台，还有小米的生态做的稀烂，在和客服人员沟通后得到了模棱两可十分不专业的回答之后下定决心把手边的小米 4A 刷成 OpenWrt，毕竟对于爱好者而言，客服就是半路出家的半吊子，毕竟解决不了问题咱就迁走嘛。本身是资深软路由用户，刷机也没啥成本。
官方的地址，看看就好
刷机之前还是很有必要先说下救砖，只能用到小米的官方工具，而且只有 Windows 版本，所有这里需要准备一台 windows 带网口的设备。
MIWIFIRepairTool.x86.zip(980 kB)
用网线把电脑网口和路由器的 Lan 口连在一起，这样在刷机工具中会看到电脑有一张网卡被路由器 DHCP 分配了 IP，192.168.31.X, 此时无法登陆 web 后台。这里建议在打开软件之前先执行这个刷机步骤：
1 断开电源，按住 Rest 键，再接通电源，直到橙灯闪烁再松开
2 打开刷机软件，这里回识别一会网卡
3 等待路由器恢复，完成之后指示灯会变成蓝色
4 然后就可以通过 192.168.31.1 进入后台界面了
这个有个小插曲：我一开始在刷机最后一步断电重启的路由器，试了两三次均不能刷入，论坛上也建议不成功的话多刷几次。没有出现需要降级路由器固件的情况。
网上提供了一个 Python 脚本来解锁路由器的 telnet 和 SSH，然后会预制一个 Buybox 的环境，其实就是一个 Linux 的工具箱环境，我们可以执行 curl，wget 等命令。telnet 的用户名和密码都是 root。
SSH 会遇到这个错误，所以用 telnet 了：
本地可以用 Python 启动一个文件服务器方便路由器下载文件，用 SCP，FTP 啥的也行
可以用浏览器访问 IP:8000 来访问文件服务器，然后 wget 提取文件链接。
Breed 更像是 BIOS 一类的东西，每次 Reset 路由器之后，就会进入到 breed 后台，IP 地址是 192.168.1.1，如果进不去后台可以把 IP 改为 C 类 IP 地址的网段，然后就可以进到 Breed 后台来输入 OpenWrt 固件了。
breed-mt7621-pbr-m1.bin.zip(95 kB)
路由器没啥空间了，所以都要放在/tmp 文件夹下，把链接换成自己文件服务器的链接。
v2.5.29 小米 4A 千兆版 OpenWrt 固件.zip(39.8 MB)
Breed 的下载页面：https://breed.hackpascal.net/
备份分区
我这里先刷的 openwrt-ramips-mt7621-xiaomi_mi-router-4a-gigabit-initramfs-kernel.bin，其实已经可以进入路由器后台使用了，然后刷到 sysupgrade 镜像，其实应该在 OP 后台刷这个 sysupgrade 镜像。
刷完之后，路由器会自动重启，此时 telnet 会断开。
把 IP 地址改成自动获取，这个时候可以进入到路由器后台了。
设置完无线的用户名密码之后有个很奇怪的问题，WI-FI 一直没有网，但是有线正常，后来在 Network 中删除掉 Wan6 的 DHCP Set 就好了。
https://www.right.com.cn/forum/thread-4317222-1-1.html
https://blog.51cto.com/xfxuezhang/5866060
ABO 血型系统：这是最重要的血型系统，包括 A型、B型、AB型和O型四种血型。A型血液具有A型抗原，B型血液具有B型抗原，AB型血液具有A型和B型抗原，而O型血液则没有这两种抗原。
Rh 血型系统：Rh 血型系统是在 ABO 血型系统之后最重要的血型系统。最主要的是 Rh(D)抗原，它决定了一个人是 Rh阳性（Rh+）还是 Rh阴性（Rh-）。因此，我们常常会听到血型被描述为 A+ 或 O- 这样的形式，其中的 “+” 或 “-“ 就是指的 Rh 血型。
所以，总共有八种血型：A+、A-、B+、B-、AB+、AB-、O+ 和 O-。
ABO 血型系统是一种基于人体红细胞上存在的抗原类型的分类系统。在 ABO 系统中，主要有 A 型抗原、B 型抗原和没有这两种抗原的 O 类型。
以下是具体的细节：
A型血：有 A 型抗原，体内产生抗 B 抗体
B型血：有 B 型抗原，体内产生抗 A 抗体
AB型血：有 A 型和 B 型抗原，体内不产生抗 A 或抗 B 抗体
O型血：没有 A 型或 B 型抗原，体内产生抗 A 和抗 B 抗体
关于父母血型和孩子血型的关系，因为 ABO 血型是由两个等位基因决定的，一个从母亲那里继承，一个从父亲那里继承。A 和 B 两个等位基因是显性的，而 O 等位基因是隐性的。所以：
如果父母的血型都是 A 型，那么孩子可能是 A 型或 O 型（假设其中一个或两个父母携带了 O 基因）。
如果父母的血型都是 B 型，那么孩子可能是 B 型或 O 型（假设其中一个或两个父母携带了 O 基因）。
如果父母的血型都是 O 型，那么孩子只能是 O 型。
如果父母的血型是 A 型和 B 型，那么孩子可能是 A 型、B 型、AB 型或 O 型（假设其中一个或两个父母携带了 O 基因）。
如果父母的血型是 A 型和 O 型，那么孩子可能是 A 型或 O 型。
如果父母的血型是 B 型和 O 型，那么孩子可能是 B 型或 O 型。
如果父母的血型是 AB 型和 O 型，那么孩子可能是 A 型或 B 型。
如果父母的血型是 AB 型和 A 型，那么孩子可能是 A 型或 AB 型。
如果父母的血型是 AB 型和 B 型，那么孩子可能是 B 型或 AB 型。
如果父母的血型是 AB 型，那么孩子可能是 A 型、B 型或 AB 型。
不同血型的人接受输血时，必须确保血型相容，否则可能产生严重甚至致命的免疫反应。例如，B型血的人如果接受A型血的输血，他们体内的抗-A抗体会攻击输血中的A抗原，导致血液凝块、器官损伤等问题。
理解 ABO 血型遗传关系的关键是知道 A 和 B 基因是显性的，而 O 基因是隐性的。这意味着如果一个人从父母那里获得了 A 或 B 基因和 O 基因，那么 A 或 B 基因将显性表达，而 O 基因将隐性表达。
用这个理念，我们可以对血型遗传关系进行一些简化：
如果两个 O 型血的父母（OO 和 OO），他们的孩子只能是 O 型血。
如果两个 A 型血的父母（可能是 AA 或 AO），他们的孩子可能是 A 型或 O 型血。
如果两个 B 型血的父母（可能是 BB 或 BO），他们的孩子可能是 B 型或 O 型血。
如果两个 AB 型血的父母（AB 和 AB），他们的孩子可能是 A 型、B 型或 AB 型血。
如果一个 A 型血的父母和一个 B 型血的父母（可能是 AA, AO, BB 或 BO），他们的孩子可能是任何血型。
如果一个 AB 型血的父母和一个 O 型血的父母（AB 和 OO），他们的孩子可能是 A 型或 B 型血。
以上简化可能没有涵盖所有的情况，但基本上可以解释大多数情况的遗传模式。请注意，这个遗传模式是理想的，现实中可能存在一些偏差。
如果你想更详细地理解每种可能的遗传模式，我推荐你使用 Punnett 方格。Punnett 方格是一种在生物学中用于理解和预测遗传模式的工具。在这个方格中，你可以表示每个父母的基因型（例如，A 型血的父母可能是 AA 或 AO），然后看看每种可能的组合。
此外，血型也在妊娠中起着重要的角色，特别是母亲是Rh-而胎儿是Rh+时，可能会发生Rh不兼容，导致新生儿溶血性疾病。这种情况可以通过在怀孕期间给予母亲抗-Rh(D)免疫球蛋白（Rho(D) immune globulin）预防。
血型在医学、法医学和人类遗传学研究中都很重要。不过，关于血型和性格、饮食偏好等的关联的说法，尚无科学依据。
]]>https://discussionschinese.apple.com/thread/253757661
直接查有线之后，速度有很大改进，原来不是随航掉帧，是路由器不行。
2.4G 干扰
https://support.apple.com/zh-cn/HT201542
没辙，换 homepod 吧，起码 homepod 还真的不错
东直门吃过午饭后，沿着安定路旁边的河流一路骑行，慢悠悠的来到地坛的南门。马路对面就是雍和宫，经常有无数善男信女来此求取姻缘。再往南就是北京很有名的小吃簋街，这附近总是热热闹闹的，丝毫找不到小说中“这院子无人打理”，“杂草从生”的痕迹，园内也是各色人等，还在襁褓中的孩子，放假休息的学生，一边游走一边电话的成年人，还有三两成群过来散步的老人。
沿着地坛外侧砖路散步，自然是脚本慢下来不在乎时间的流逝，一方面是为了找寻小说中提到的地点，另一方面也是想要亲眼见证石门下被照的透亮的坎坷。出门时候尚未规划好行程，又临时起意来到这园子，打算看这里的日落，是否会如湖面一样拖起长长的影子。参观祭坛要额外买票，在我从前去过的许多园林之中，祭坛多被虚掩起来，虽然现在早已不再从事祭祀的活动，所幸遗迹被肉眼可见的保留了下来。
正午的方泽坛，我装做皇帝一样走向高台，穿过外墙进入内墙，然后一步步的迈过阶梯，前面有人拍照也丝毫不去避讳。登上祭祀台，已经简化了很多东西，目前的摆设是遵循1750年乾隆时代的摆设。方泽坛对面是皇祇室，大堂的中央摆放着皇地灵位，左右内侧摆放着清代卓越贡献的几代君主的灵位，从介绍得知，他们的肉身葬在我不曾听过的地方，左右外侧供奉五岳、五镇、四海、四渎、五陵山神，而皇陵大概率是龙脉所在吧，惭愧对大清历史不求甚解，也不想亵渎前人再去抄送。破旧残缺的青砖总会让人想起故宫，甚至是影视剧午门问斩血溅五步的场景。祭坛低矮墙壁的角落里，有人在练习拉伸，有人刚刚把刀从鞘中抽出来，一时无法分辨刀是真品还是高仿，加上这人的穿着，颇有反清复明吕四娘的装扮。假期里来参观的人自然不少，父亲给孩子讲解着祭祀的斋戒礼教，男人躲在角落打电话谈着生意，小夫妻在拌嘴，走马观花后觉得不该来此，还有三五成群在这野餐拍照留念。我呢，在进门之前摘下耳机，登上这祭祀的高台，甚至已经想好了焚香祷告，烹羊宰牛的画面。殿中前现存的大多是复制品，确实无法像真品那样让人怦然心动。
去年在故宫大殿参观的时候是有真迹的，我鼓足勇气与石像对视，这石像经历了战国争雄，五代十国，以及数不清楚的动乱时候仍然总算完好的保存了下来，过去的创造他的人早已深埋黄土，几百甚至几千后它还会伫立在这里，变的只是一批有一批的瞻仰者。若不是空气中弥漫的腥臭的味道和铭牌上距今几百上千年的字眼过于突兀，我会沉浸在无尽的历史长河中久久不能回神。还有在东直门某博物馆看见的函谷关的瓦当，不得不又回溯起楚汉争入关中那段荡气回肠的历史。
从祭坛出来后，继续播放《我与地坛》的有声读物，重游重温一遍内容，新鲜的风景和记忆里尘封的旧的内容交织融合。他是后天的残疾，最后也没有看透生死，只得出来生没得选死不必急于求成的结论。倘若生下来从未体会过奔跑的感觉，那么便也只能怨天尤人，要是他一蹶不振不再写作，那就是另外的故事了。这是否又是今生来体验人间苦难的下凡？不管怎么样，我从不把这种这当作励志的故事。
于是我开始去设想从前的园子，大小应该不会有很大的变化。但西北口钟的那十分破旧的那一口钟现在已经无从得见，到处的荒野杂草野路被修缮成了整齐划一的灰砖，不变的是，倒还能在路边看见近乎晒干的了蚯蚓。尽管现在重修了钟楼，封闭了马厩，同时又加上了诸多娱乐设施。只是现代的气息太浓，若来追忆经典定会觉得索然无味。还好能找见几棵400年前明代的古树，不远处还有一个妇女在教孩子聆听树的声音。上了年纪的树自然是被铁圈围起来的，让人不自觉就想起摇曳尾于涂的典故了。而古树的枝条上，总会紫藤会围着这样的老树生长，交织和抱，开出淡淡的小花，引得路人争相过来拍照。园子北侧翻修的太彻底，丝毫没有小说中的痕迹，我尝试在树的附近寻找史铁生车轮的痕迹，当前正如他所说，这园子正在被不懂它的人精心雕琢。现在每个公开场所都有所谓的商业模式，这点798为首的文艺社群中尤为突出，自然地坛也无法幸免。来地坛之前，在想象是多么幽静的环境，比人高的杂草，以及东南角那高亢嘹亮的声音，每天从北到南从南往北的女工程师。现实却是丝毫没有桃花源的感觉，似乎成为人们茶余饭后来消遣的场所了，又不由得感叹现代人肤浅的享乐简直来的太过容易，无论每个公园都会有游乐设施在大煞风景，还有不知道是哪个年代的流行歌曲一直响个不停。思绪拉回现在，老人们在吹奏手风琴还有小号，另外一旁还有正在进行的门球的赛场，倒是孩子们在无所顾及的疯跑嬉闹。
但，对于这园子的一年四季，我总是无暇来观望的，就连楼下的后花园也很少去宠幸。除了文中提到的雨燕外，还有喜鹊，乌鸦，鸽子这些鸟类，算是为数不多超出作者的笔墨吧。倒是最近每年清明都去龙潭湖散步，看鸭子高飞，鸳鸯戏水。大概是距离首都图书馆比较近的缘故吧，常常是在潘家园的二手市场中恣意寻找后骑车到方庄。但别人用过的东西从风水上讲毕竟还会残留上一个人的精气，还无法完全接受。
在我那密不透风的学生时代，总觉得许多异乡游记是和三皇五帝一样传说的故事，而我却生在一个山高皇帝远的地方，守着些不为外人道的自然风光。甚至我在工作以后才有机会到一些不算太远的旧址吊唁。比如渤海湾曾经甲午海战的地方，东鸡冠山上到处是日俄战争枪林弹雨的痕迹，就连误入的墓群主人，也分不清到底是旧时的未亡人还是几年十几年甚至几十年前疲于奔命的过劳者，甚至脚踏的这片四方黄土就是乃木宝典战死之处，还有作为标志性的建筑的弹壳，我甚至不愿想象战争年代白发人送黑发人情感被上司大如天的威严严苛所淹没，死后被历史记住已经是最大了补偿了。大连是到处都有墓碑的，在每一个所谓现代定义的景点公园，凡事对外的，总会在一不留神间瞧见墓碑或者墓群就在不远处。中日之间是有宿命的姻缘的，这点在那些发生过大规模屠杀战争的地方尤为严重。大连的每一片土地都渗着鲜血，有革命先烈的，有当代年轻人的。当地的大户说，采集百年弱冠的血，用温热的殷红把混着泥土的陈年凝块化开，喝了可以长生不老。
故宫是溥仪的家，地坛也是史铁生的后花园。至于龙潭湖附近，长眠着一位《碧血剑》中的故人，功高盖主而殁于崇禎。两次拜会，第一次因为疫情，第二次由于天色渐晚行到庙前又不忍打扰。倒不是有多喜欢古迹，除了闲逛外，多半是朋友邀约或泛读诗书自然想去凭吊一番。
十九点按时日落，大概是因为现在楼宇太多的缘故吧，守了一个下午，从中午等晚上，一直到路灯亮起，也没有在祭坛的石门前瞥见落日的余晖。索性来到簋街，在胖妹面庄的胡同前排起长长的队，再顺手把这些记录下来。
2023年4月29日于地坛
上学后，
雨是城中疾驰的孩子，
结队成群疾行风中
前有单车，后有乌云，
一盏日光灯悄悄驱散阴霾。
工作了，
雨是都市湿漉的地板，
半干半湿透着氤氲，
昨夜雨疏，今夕风骤，
一个外乡人匆匆留念海棠。
其实呢，
雨该是镜湖踉跄的渔夫，
驿外断桥咏叹春梅。
清者濯缨，浊者濯足，
一代文化人静静独留风骨。
从能力或者文凭来看，中国人更加趋近于文凭，一部分是为了面子，在邻里之间吹嘘，好似现代版读书人的事叫盗而不叫偷，另一部分是为了尽可能的避免别人像被挑白菜扔来拣去。做营销的人总会有一套，先给你制造各种各样的焦虑，然后宣称自己有灵丹妙药。从当今互联网的招聘状态来看，颇有捡芝麻丢西瓜的意味。从某种程度来讲，我们所谓的快乐式教育已经荡然无存，家长一方面希望孩子能一个快乐的童年，而另一方自己有深陷漩涡，希望下一代续写昨日的故事。所以，这样的单纯，善良最后就都变成了无知与不作为残害的牺牲品。甚至不知道我们为了什么以及为什么要这么做。
喜欢看武侠，风清扬说最厉害的招式不在武功之中，而是阴谋陷阱。这句话在这里也同样适用现在的教育，资源在少数人手中，算是寒门再难出贵子的境况。暂且不论这样的教育弊端如何，但在传统儒家的观念里的尊师重道仍然被保留了下来，但是却不会有对于道德的一些标准。于是我们常常在讲，是招一个道德好但是能力一般的人还是没什么道德但是专业能力很强的人？大概是从陈平开始，从举孝廉到任人唯能，所以汉王灭楚，魏武伐仲。宋襄兵败，任侠多累。
古代的功名利禄，是和科举考试有很大关系的。至于后人妄论八股骈文，却是身在其中而不自知。又有一群人，不管心里怎么想，但是做给别人看的总要符合这个身份和当时的规则。从这点看来，现在的人没有气节，也可以称的上是某种程度的投机分子。假意逢迎不合理的制度并且为了追求自身利益最大化而劳心费力，这样的人多了，就会对这样的环境起到了正反馈的作用，从人性来讲，不反对等于隐式认同。这其实和抗战时的汉奸特务无疑，他们也只是在居无定所中安身立命，尽管这会奴役和残害自己的同胞。但，对于国素质而言，从某种程度来讲， 冷漠遗忘不作为，却更胜于杀人分尸，路边人的健康温饱甚至生死，依旧不会被关心。偏偏很大一部分人又喜欢站在道德制高点来讲述这些话。唯一不同的一点是，现在人不必被钉在耻辱柱上，因为残害杀人的定义，是由律法来决定的。
文人的圈子中从来不缺乏批判，但单多半只是自娱而已，伴随的还有求而不得。只有身居高位才能付诸忧国忧民，血染疆场才能保家卫国。而治国之策能否施展，自然有历史为证：贾生才调，武侯余生，东坡鹰犬，放翁镜湖，嵇康放荡，阮籍穷哭，守仁流放，嗣同快哉。
回到现在。纵有诸多不适，但总归会隐忍着走完这一程，随之而来的是被贴上言简意赅的标签，然后用机械化的方式来查询 SQL。似乎现在的一切都能用古代文字来解决，“世有伯乐然后有千里马，千里马常有而伯乐不常有，故虽有名马，，，。安求其能千里”。教育可以做什么，历史可以带来什么，似乎有一双看不见的手，伸出大气层，蒙在了太阳之上。我们可以不关心国际形势，因为这是政治家的事情，当然也可以不关心战争，按照俄乌的节奏，世界大战是早晚的事，那其实科技也不必关心，程序员成了码农，人机融合遥遥无期。
小人物又能做些什么呢？余华笔下的福贵是凄惨的，莫言总是在讲述村野往事，韩寒的天才少年在夕阳下凌乱。在某个不经意的瞬间，我时常想起屈原的渔夫，苏轼的洗儿，陆游的咏梅，以及闻一多的暗杀……
]]>ventoy 是一个可以支持启动很多镜像的工具，可以理解为 win + linux 的版本的 PE。现在也兼容了 openwrt，chromeOS， EXSI 这些系统了，虽然还不支持 MacOS 哈哈哈哈
现在民间有萝卜头的 Windows To Go 辅助工具|WTG 辅助工具 v5.6，可以轻松的安装系统到 U 盘。
https://bbs.luobotou.org/thread-761-1-1.html
我的系统是 CZ880 的 256G 版本,读写均可达到 400MB/S 左右，这个速度已经很接近 Sata3 固态硬盘了。
有时候不想让 ventoy 显示其他的东西，比如黑苹果的 EFI，office 的 ISO，这样就需要设置显示 image_list 的白名单。
就是在 ventoy 目录下 ventoy.json 这个格式，而且只会显示这里的镜像。
1 | { |
PS：找 chatgpt 要了一份自动生成 json 文件的代码：
1 | import os |
12 核 16 线程其实是 4 大核 8 小盒，所谓大小核问题，就是在以 vmware 为首的很软件，经常出现小核跑满大核限制的情况，然而在任务管理器中还显示 CPU 占用 100%。
需要在电源模式中开启性能模式，然后才能解开大小核的显示，后续的时候没有发现特别不适应的地方。
因为主机是双 HDMI 和双 typec 的接口，所以必须要接一台 typec 的的显示器，但是 Philip 网红显示器接上有很长的延时点亮问题，有时候甚至比开机时间还要长，同时也咨询过 intel 和 Philip 的售后支持人员，答复如下：
另外显示器有时候不能 4K60@刷新，客服说要把显示器的 hub 改成 2.0，但是这样就只能接一些键鼠摄像头一类的东西了。
2.5G 驱动目前好像只能离线安装。目前 win10 和 win11 系统内部没有集成 2.5G 网口的驱动，所以需要手动去官网下载驱动，然后手动安装。这里不太推荐驱动精灵一类的第三方软件。但是其他驱动只能联网之后安装，所以还是先准备个 U 盘吧。
win11 虽然很丑，但是据说只有这个对大小核兼容好一点，现在只有企业版核教育版可以不用强制登陆 MS，其他的都绕不过去，有的输入神秘代码亲自测无效，估计是 MS 家修复了这个问题。
装好系统之后，遇到了 C 盘占用特别高的问题，网上查询之后是因为内存太大，导致 OS 自动做了休眠文件，为了把内存都压到磁盘里。
唯一值得安慰的是 PCLE4 的 NVME，顺序读取有 6600MB/S，总之还算不错。但是总归是 TLC 的，毕竟我连 MLC 都能写坏…
前两种基本没有什么差异，不过需要手机和电脑分别安装打印机驱动，无线的可能支持微信无线打印，但是用盒子自己改的目前还不支持移动端，这种一般是打印机使用连接路由器，一般公司是这种。
当然有办法可以让手机不用安装驱动，需要使用 PC/MacOS 安装驱动之后再局域网共享打印机，这样 windows 和安卓都能搜到。
有一些老式的打印机会出现苹果设备搜不到打印机的情况， 是因为没有兼容 airprint 协议导致的。当然新的打印机无需考虑这个问题。曾经有个 airprint 的软件，现在已经停更，也不想折腾了。Anyaway，劝退 apple 全家桶的最后一根稻草。
]]>淘宝买的猪小肠的肠衣，以前也使用过其他肠衣，效果不好。基本上是腌渍的肠衣，回来用料酒泡了一个多小时，然后用水冲了几遍场子内部，看看有没有坏的地方，有小孔不影响灌肉的可以忽略。
趁着清洗肠衣的时间调制肉馅，用绞肉机打碎，加上卖家的肉料（其实也可以自己调制），每斤肉加入30g淀粉，用来填补肉之间的孔位，红曲粉看颜色放入，差不多一斤肉0.5g的样子，主要为了颜色发红，多了会暗红。这个添加剂据说无害。最后加入葱姜水，六斤多肉我放了两碗。搅拌到最后越来沉，是在没力气搅拌的拉丝，直接就下一步了。
使用用灌肠神器，其实就是一个大号针管。视频里都是很顺利的灌进去了，我这个有肉堆积的现象，然后得用手一点点往下缕，不然会撑到爆开。 把肠衣完全套在神器上。灌好之后用绳子打结，分出每根的大小，最好打两层的绳子，保证切的时候不会破坏肠衣，然后用牙签戳，防止煮的时候肠衣爆开。完事之后进行风干操作，屋内低温自然2小时或者烤箱30风干30分钟。
风干之后可以继续扎眼，然后冷水下锅煮，中间可以自由翻面，有明显气泡可以直接用牙签戳破。全程小火，开锅了就加凉水，40-50分钟之后香肠都飘起来就可以了。记得扎两层绳子，防止切的时候肠衣剥开。 
煮好的香肠可以冷冻上，吃多少烤多少，煎炒烹炸都可以。烤箱的话180度15分钟就可以，想吃脆皮的可以多烤一会。
基本上做出来的和网上买的火山石烤肠相差无几，不过自己家做的纯肉的，99. 99%纯肉，外边的比不了哦。
大概是从自制插排开始，一把 10 元螺丝刀螺丝刀开始，自制插排，换插座吗，就把线接一起就行，没啥难的，注意接的时候断电。
如果你想自己做插排，你可以使用以下步骤：
准备材料：你需要一个电缆，一个插头盒，一些电线和电缆接头。
切线：按照需要的长度将电缆切为若干段，并分别给每一段线剥去绝缘层，留下裸露的电线。
做接头：将裸露的电线与电缆接头相连，并给接头做好绝缘。
安装插头：在插头盒中安装电缆接头，并确保每个接头的接触良好。
测试：插上插头，确认每个插口都能正常工作。
注意：请确保使用适当的工具和安全设备，避免造成危险。如果你不熟悉电器装置，建议请专业人员帮助。
手残党哎，一言难尽。忘记留图。以后争取买一把好的电烙铁。
以前是因为路由器和电脑网卡不行导致延迟太大，所以需要自己做一段网线，需要买网线钳，水晶头一类的东西。另外顺便把光猫和 NAS 的网线也给换了。
蓝色是自己做的。
如果你想要做网线，你可以使用以下步骤：
准备工具：你需要一把剪刀、一台网线剥线器和网线插头（RJ45 插头）。
剥线：使用网线剥线器将网线剥去外层的绝缘层，留下八条裸露的线芯。
分类：根据网线插头的颜色代码将线芯分为五组，分别是白色、橙色、绿色、蓝色和棕色。
排列：排列五组线芯，按照颜色代码将线芯排成一条直线，从左到右依次是白、橙、绿、蓝和棕。
对接：将网线插头与网线相连，把排列好的线芯插入网线插头中，直到线芯完全插入插头。
测试：使用网络测试仪测试网线的连通性。
注意：网线插头的颜色代码有不同的标准，在选择网线插头时请确认使用的是适合你的网线标准。
其实现在的网线都是 B 类的直通线，网线线序 xxx，不够据说现在的交换机都能智能识别线序，从二层这里兼容了双绞线和直通线，当然本人偶尔也有把线序弄错的时候，但是竟然还可以正常传输，这点不得而知。
学生时代买的 10 元螺丝刀用了很多年，遇到其他尺寸也要单买不同的规格，况且买东西经常赠送小螺丝刀什么的，每次换一个地方都要买一个螺丝刀套装，miniso 的 15 元套装也用了很多年。不过入手了电动螺丝刀之后兼职不要太幸福，拆电脑，门锁窗户把手都是分分钟的事。按左边拆螺丝，按右边拧螺丝。
外面的面条不知道什么材质做的，怎么吃也感觉吃不饱，就是胀肚还觉得饿，大脑也没有能量。
应该是望京这边最好吃的面了，能免费续面（大碗），但是不能免费加汤。首重三两半，续重二两半。单买了肉末和豌杂。
有打油诗为证：
挑战一天内只吃刘胖妹面庄
刷新店内最高续面记录失败
和老大哥差了二两半的白面
不愧网红的小面店下次再战
从三里屯种草之后就一发不可收拾，三十多一碗的价格不续面都觉得亏，用草本汤稀释番茄汤味道不错，最高记录6碗，可以免费加香菜，现在改了菜单，理性考虑吧。个人感觉沦为路边小吃快餐水准了。（有些店完全没有中国风的感觉。。。
ps：已经粉转黑
号称拉面界的海底捞，其实就是普通的兰州牛肉面，觉得跟和府捞面的牛肉面也差不多。好处是无线续面，店里人一直不少。
羊肉串比较薛定谔，有次用的打折券就很难吃，串又小又苦，很难不让人觉得有什么猫腻。之前单点的还行。
外地人慕名而来，其实还没自己家的炸酱面好吃，商业化了之徒有其表，不怎么推荐。拌面续面的结果就是吃着吃着就凉了，不给加菜，还是第一次续面吃不下去的，排队很长。酸梅汤和拌肚很不错。
商场角落的一员。打折券13.9还能无限续面，不过每碗面很少，不过不耽误我吃6碗，最后辣子鸡很不错。
要带菊花链
现在有 airpod pro2， qc45，华强北 airpod
地投幕布
可以自己换水自己换垃圾那种
4415U 缝缝补补还能再战三年
尽管网上关于程序员修电脑的段子已经层出不穷了，似乎大多数人也不再吐槽程序员修电脑这个事情。事实上，不管走到哪里都总会有人找我修电器，从广告 LED 屏幕，电子秤，再到手机电脑，电视盒子，最后到路由器。所以当别人问我大学读的什么专业，我干脆回答修家电的。
我似乎已经形成了习惯，不管走到哪里都要准备一套趁手的设备：螺丝刀套装，钳子，万用表和绝缘胶带，准备了这些电工和网工必备的工具来提升维修的效率，至于网线钳实在是太累手，已经抛弃不用了。
这几年 NAS 的成品百花齐放，有对爱好者入门很友好的群晖，有适合更加专业一些的威联通，甚至于联想和绿联这样的商家也纷纷推出成品来降低使用者的门槛。其实驱动着自建 NAS 的爱好者不断折腾不过以下几个原因，网盘限速，限制文件大小，还有各种网盘的不定时监控。在我自从被用百度网盘被莫名限制文件下载之后，便开始了在家里自建数据中心的想法，这样就可以不受拘束自由的下载和分享文件。实施下来除了晚上各种网线灯和电源灯的光污染之外，其他方面提升了很高的幸福指数，上传下载可以跑满家里的千兆内网，也可以分享体积大于 5GB 的单个文件，至于存储空间就取决于钞能力了，也希望早日能够实现家庭百 T 存储的梦想。
一开始由于资金的原因，我打算在 Centos7 上自己部署一些开源服务，但是鸟哥私房菜实在太厚啃不动，加之后期的维护成本巨大，每个服务维护起来都要敲指令。后来我索性花重金买了 QNAP 当红机器，同时也不定时和同学柜子里的黑群晖在做着异地同步。在这一切准备完毕后，我找到了联通公司要了动态公网 IP 地址，结束了与内网穿透的相爱相杀的艰难的日子，同时利用闲置域名设置了一套动态域名解析，用手机随时随地连回家里的服务。唯一遗憾的是回老家是用树莓派做的网页监控也经常被运营商封掉，后来从群友处得知 80/8080/443 这几个端口不能使用，联通客服只能从后台看见网络状态，其他的超出了支持范围，同时也驳回了我想去找网警咨询的要求。
后来了我解到，如果是在家里建站好像是要和公安部门申请的，走一个类似备案的流程。而联通的上传带宽只有 30MBPS，似乎满足不了随时连回家观影 4K 电影的需求。在极客心的驱使下我走上了单宽带叠加的路程，使用家里 200M 的宽带同时拨号三次可以达到 550M 的网速，再后来趁着活动免费提升到了 500M，单线多播这才告一段落。但是搬家到北京之后，出租房的网络太差并且带宽只有 100M，在因为网络不稳和在经历了无数次和运营商以及二级运营商的扯皮后，只能选择额外加上一个其他运营商的线路，京东下单了小米 AX5400 路由器，在上边设置了一个双宽带叠加。相对而言没有软路由那么自由，硬路由的叠加只能是不同的运营商的宽带，比如移动和联通。而且运算速度也不如 X86 架构的软路由，优点是 NAT 性能很好。所以还是推荐软路由加上个普通路由做个 AP。
经过群友不完全统计，有些地区的运行商很大方会直接给公网 IP，有些地方运营商政策不一，需要等一定的时间，然后手动更改为路由器拨号。还有一些运营商甚至明码标价，公网 IP 每月固定收费，这个典型的代表就是北京移动。
解决了存储问题后，下一个面对的问题是网络。我想到很多国外的设备仍然需要连接海外的服务器进行激活，比如 Oculus 的 VR 眼镜，包括 Google Pixel 在内的原生安卓，这些都需要在连接海外服务器的情况下激活，这样的功能默认在国内是无法使用的。所以我想玩的痛快游一些，于是便在路由器的上挂一层代理，这样电脑手机都不用安装专门的客户端了，甚至连 kindle 都可以愉快的科学上网了。我折腾了下面三种：
这种产品现在已经成为产业链了，主要供货渠道来是各个平台短视频平台的科技 UP 主，基本上是一次购买终身答疑的制度，还有对应售后的微信群以及用于下载资料和固件的博客网站。对于小白用户，大概要熟悉一周左右，需要安装 EXSI 和两个路由器系统虚拟机，其中一个是国产路由器操作系统 IKUAI，另一个是大名鼎鼎的 Openwrt。再把网卡直通（类似 EC2 的增强联网）。IKUAI 的系统是免费的，也可以在这里安装虚拟机安装 openwrt，当然禁止套娃。Openwrt 在 Github 上有源代码和 release 文件，也有开源的编译方法。这里有个小插曲：
a) 我装系统一直用的 ventory，出现安装之后无法启动的错误，给技术支持打电话之后，的工程师表示镜像没有问题，换了刻录镜像的方式之后可以安装。后来调查应该是 ventory 的支持不好。
b) 用自己的四核笔记本电脑编译 OP 源码，几个小时 CPU 一直满载，风扇噪音比冰箱制冷的声音还要大。（我的冰箱因为压缩机问题本身噪音就很大，妥妥的人工噪音）
实习的时候部门老大过来跟我闲聊，他说把家里的 AC86U 刷了梅林固件，后来因为信号问题影响孩子写作业又刷回原厂固件了。梅林固件我是用的斐讯 K3 刷的，江湖人称漏油机，好像是因为散热的硅脂不太行，只要加热就会有油析出，拆开之后散热器上是油和灰尘的混合体（画面太美就不放了，想看可以移步朋友圈）。而且斐讯的其他产品也可以随便刷机，我把两个 K2 分别刷了 openwrt 和Padavan的系统，N1 和 T1 都刷成了安卓电视盒子，其中个人觉得 T1 作为影音系统的效果更好一些。不过 N1 还可以刷成 openwrt 制作旁路由。
我的网络理论知识不太行，虽然不懂原理，但是按照提示把主旁路由设置为相互的网关之后，屋内的设备就能愉快的上网了。这样流量每次都会在旁路由上转一圈，然后能做的事情就更多了。
当然言归正传，折腾完之后还是有一定的维护的成本，这一套部署下来家里感觉变成了一个 KTV，24 小时的噪音和灯光污染，软路由的网线口已经基本插满，家里每晚都闪烁着黄绿交替的灯。当然是黄灯闪烁，绿灯常亮。在一次在通电的情况下拔掉系统盘导致了磁盘坏块，如下图，数据丢失，虚拟化需要手动操作，然后上面的流程又需要重新开始。
虽然大多数折腾的产品都很耗费时间精力，不过还是极大的方便了我的生活。在有了外网环境之后，下一个要折腾的就是原生安卓系统了。
我是四年的米粉换了 Iphone，还要从小米 8 刷原生安卓开始，来叙述这一段爱恨情愁。。。。。。
我在换了苹果全家桶之后，有种整个世界都安静的感觉，不用经常清理内存，也不必忍受普铺天盖地的广告。相信对于大多数爱好者来说，折腾安卓刷机的那个年代还是还留下了很多美好的回忆。对我来说，一切都是从高一那阵给同学手机刷机救砖开始，同学在手机 root 之后删除了系统关键文件导致无法开机。于是我一直花费整个晚上去找适配 Android2.3.5 的 ROM 包，到后来也会尝试用一些软件破解手机锁屏密码，比如爱思助手，奇兔刷机之类的。直到最近几年，国内各大安卓厂商技术已经相对成熟，刷机精灵也早已倒闭，在安卓系统开始变得封闭的那段时间里，我渐渐忘记了安卓刷机的事情。直到有一天，我手里的小米 8 在过保后经常屏幕反复黑屏，系统变卡之后，我终于忍无可忍重操旧业。正巧了解到有个关于原生安卓的开源项目” MoKee“，这个刷机步骤和以前大同小异。如果是品牌手机需要把系统降级到开发版，然后刷入 TWRP（也就是以前的Recovery），最后双清卡刷 ROM 包。由于我在家里已经安装好了软路由，激活时候完全不用担心连接国外服务器延迟卡顿的问题。终于在刷机完成后，我的小米 8 好似复活了一般，清爽的没有广告，和三星相似的 UI，再装上 Google 三件套，我仿佛嗅到了自由的味道。
然而好景不长，大概半年以后，原生安卓的系统出现了和国内硬件水土不服的问题，经常发生内存爆满，应用卡顿，需要多次手动释放内存才能正常使用，而且还有很多本地化的功能无法使用，比如 NFC 门禁，小米公交钱包。而我在因为手机卡顿无法刷码差点被赶下公交车后，便开始尝试其他社区的官改包了，所谓官改包就是在官方的包上剔除广告和预装应用，然后再加上一些提升效率的小工具。我找了一个人气还行的 ROM，不过在刷机期间发生了一点点误操作，安卓不小心被刷成变砖头了，还是出现了熟悉的兔子界面，玩笑一语成谶。而对于小米来说，官方从根源上解决了用户自己救砖的问题，用户使用自己的设备刷机还需要官方的授权密码，而维修店的刷机设备则不需要。我在和小米官方售后交涉了小半年之后，终于在用 9008 免密刷机的方式刷回了最新版的小米安卓系统。还真是应了群友的话，愿你刷机半生，最后 MIUI 养老。
在分享过这个经历之后，便有朋友过来向我请教把手机刷成砖头的”秘诀”了。
除此之外，闲来无事翻出来一个闲置的 36W 的三色 LED 灯，我起初想本着废物利用的原则，然后又买了一段 220V 的开关延长线，淘宝了买羊皮纸做了个简单的照明灯壳子，也用了闲置的米家智能插座。
对于 IOS 设备来说还可以和 Siri 进行联动，只需要在快捷方式里加上一个唤醒米家设备的设置，最后用 HomePodMini 唤醒智能设备，唯一美中不足的是京东海淘的音响的是英版的插座，需要买额外的转换插头，如果用多口氮化镓的话会还重新分配工功率影响使用。此外 HomePod 还可以作为屋子里所有 Apple 设备的音响，无论你是 MacOS, Ipad 还是 iphone 都可以无缝连接，HomePodMini 是名副其实的 WIFI 音响，你值得拥有。
除了电子设备之外，生活总会有些突如其来的小插曲，比如洗衣机坏了，面板报错 E3，朋友在电话里告诉我盖子传感器有问题，开微信视频指导我修，怎么拆盖子和电路板。我在和厂家确认过维修价格之后，便驳回了房东给的报销，还是自己拆更放心些，洗衣机报错盖子盖不严，拆机后发现传感器生锈了，最后使用了 320 目砂纸打磨搞定。一段时间过后，在某读书群认识一个同样修过洗衣机的姑娘，跟我讲如何给家里更换洗衣机电路板。顺便还晒了一波男朋友给的全家桶 – R2S，Pixel 加上 Google 三件套。她也给男朋友订阅了 Jetbrains 全家桶。
我甚至有个大胆的想法，希望以后传统家电的厂家可以暴露给用户一些接口，让用户写代码或者使用图形拖拽的方式来对品牌家电进行互联，等以后有了房子后搞一套 HomeKit 智能家居，下图是我现在用到的智能家居的 app，给各大厂商定一个小目标，就希望有一天可以互相整合开放 SDK 吧。
高级设置 -> 其他 -> 双 WAN 设置
注意：
1.开启双 WAN 功能后会与部分功能冲突，若仍想使用冲突功能，请先尝试关闭双 WAN 后再试
2.若某些终端设备出现金融类 app 无法正常使用的情况，可尝试在“WAN 口策略”功能中将该设备设置为“WAN1 优先”或“WAN2 优先”后再试
3.请勿将 WAN1 或 WAN2 口与其他 Mesh 组网设备相连
设置完成的结果
刚毕业租房是 40 平米的公寓，实际也有 30 平，租金是全部的实习工资。学校蜗居够了，不想再委屈自己。来北京刚开始只能合租了，后面黑中介，无良二房东，奇葩室友都见识够了，然后自己自己住了，一般中介都会虚标房间大小和朝向，还是得实际去看房。看房子的话，心理先有个预期，如果没有心仪的房子怎么样。如果是地下室或者一楼性价比再高也不要去看了，尽量租新一点和治安好的房子，北京老破小太多了，可以住，但是定期要去市区溜达吃点好的。看了没相中只会浪费时间。职场人首先要活的体面一点。
不要觉得房子只是一个睡觉的地方，起码的生活设施要有：稳定的水电网，燃气和隔音(手机有很多 app 可以测试分贝，大于 60 的房子就不要选择了)。而且之前疫情影响居家办公已经是家常便饭了。贵点不怕，总之还是要让自己觉得舒服。
朝向： 南>东>西>北
如果不是实在差钱的话，还是建议住在公司附近或者通勤方便的地方，很多人说单程一个半到两个小时。五环以外都是村里了，基础设施和人文设施和市里完全没有办法比，为了省心的话，还是住在繁华地带，毕竟一边工作也要一边生活，不然去市里总有村里孩子进城的感觉。二来北京可以玩的地方很多，地铁站附近去市中心也就半个小时。通勤要算往返时间，尽量减少换乘的等车时间，单程半个小时往返就是一个小时。能坐地铁不要坐公交，人多很挤，乘务员人工报站，还要维持车内秩序，没有降噪耳机的天花板建议慎选公交通勤，无听之于耳很难，很消耗精力。就算下班晚，23 点左右公交都没有座位。另外北京有共享单车，可以选择单车+地铁混合交通，单车会员每个月 15 左右。
不建议极端天气去看房，会漏调一些点。一定找不要临街的房子，五环以为打车没有管制，窗外 24H 大车通行。
第一条，选择搬家好搬且轻量的东西，买之前想好搬家怎么处理。然后才是其他，同城搬家可以无视，因为有某拉拉这些，百元以内师傅给搬(非广告，遇到的师傅可以，但是 app 做的很差，客服跟僵尸一样)。毕竟北京房租高，自己买点小玩意跟房租比根本微不足道，就任性的买买买吧，毕竟以后结婚了就不一定有机会了。(最近看中了一套设备 10W+， NUC12 飞龙峡谷和 M1 Ultra 双机双显示器，apple 官网推荐的屏幕)
现在基本都离不开电脑，有大桌子的买大显示器，否则就 15.6 便携屏（typec 一线通），还能带去图书馆。建议双屏或者带鱼屏，幸福指数提升很高，MacOS 用户可以用 slide bar，win 用户用 duet 都可以把 ipad 当作拓展屏。建议显示器预算 2000 左右，分辨率 4K@60HZ。现在轻薄本也性能炸裂了，没必要买大机箱，台式机的话 Macmini 和 NUC，APU 都是不错的选择，或者干脆买的轻轻的Macbook Air或者Thinkpad X1.
关于机械键盘，如果你的房租隔音好，放心用青轴和茶轴，万一被听见，还能给人留下半夜认真写代码的印象。
嗯，夜深人静的时候一定要选一个暖黄色的灯光，会觉得柔和放松。
还有，多备用几个插排，自己备个路由器，防止别人在公用路由看见你的设备和智能家居。
大型洗衣机（4L 左右）：自从在学校看见有人用公共洗衣机洗鞋，再也不用这玩意了。某鱼，某宝，某东 500 以下能买到很好的。（个人觉得别人买的洗衣机最多值 200）
内衣洗衣机： 懒癌晚期，不想手洗，还有内衣洗衣液。
洗鞋机： 因人而已。
便携式烘干机： 如果不是朝南建议入手一个。
消毒酒精：家中常备，可以买个自动喷酒精的机器
降噪耳机： 2000 左右买个降噪耳机绝对值得，就当投资自己吧，开降噪听着音乐假装进入元宇宙。
厨具：单身贵族不推荐了，能清水煮就行了。毕竟打折券很多，北京很多美食羊毛可以薅。豆浆机是个 bug，大的豆浆机一个人喝不完，小的费半天劲就一杯还得浪费时间清洗。
灯具：自己可以换个好的搬家拆下带走，如果中介免费给换就更好了。
窗帘： 自己可以换个好的搬家拆下带走，没必要买自动电机。
拖布和苕帚：自己屋里备一个吧。
垃圾桶和垃圾袋： 不多说。
床上小桌子：不知道为啥不给上床下桌，床上是真舒服。
即热过滤饮水器： 自带过滤3S 出热水，适合不喜欢和水龙头水的人。偶尔也得买点矿泉水喝。
公交卡：手机 NFC
你的预算够了，遇到素质高的室友概率也会大大提高。当然能租开间最好，群租大家回家都是各回各屋，交流极少。
出于公共资源利用效率考虑，还是建议和室友们错开起床和睡觉时间，判断一副眼镜舒服的标准是你感觉不到它的存在。好室友的标准也是也感觉不到他的存在（eg：你上班了，他还未起，你睡觉了，他还没下班回来）
有些女室友通常不化妆不见人，所以女室友洗衣服做饭的时候就委屈一下错开空间吧。有些女室友不成熟，小孩子气，还有的茶，总之不要希望通过合租能找到女朋友。
一定要找个靠谱的中介，你第六感有一丝丝不舒服就不要租了（比如看起来就不厚道的人），因为不知道以后还有什么狗血的事发生，进入的社会才发现，很多的人不要脸的没有底线，无底洞。高素质的人没必要惹这个气受。如果你觉得中介不给办事但是自己可以解决的话，还是建议不要浪费这个时间，北漂人时间很宝贵，不管你是 996 还是 965。
比较靠谱的:
据说假房源很多，低价吸引的：
哪个中介都会有一些负面信息，房东直租也有坑，记得用法律手段保护自己，50 块开个民事诉讼之类的。
慎选小中介！！！！！！不要先交定金
（如何投诉黑中介，待补充）
如果是和房东手里租，查好房产证和房东身份证，留作证据。
从中介手里租的话，随便怼房东吧。（不清楚房东和中介的 py 交易是怎么样的）
也遇到过冬天暖气坏了房东不给换的情况，在行业无良的中介和房东很多，纯看运气。
公共区域基本都是先来先占用，不需要过于考虑其他人感受，毕竟大家都可以放东西，别太乱到过分就行。毕竟花钱租了房子，说话硬气点。记得查好水电价格。
每个人的忍耐程度不同，不要人云亦云，说你事多的直接怼回去，毕竟都是试探对方底限。别委屈自己迁就别人。
跟你说 GTD 没用的都是没做好的，靠脑子真是记不住，冥想+GTD+复盘，形成规律，别在决策上浪费时间。
北漂人很忙，但是不要慌张。
]]>太早了没几个电话能打通，无奈只能 120 你要救护车吗，我们只管派救护车。高德上电话基本打不通，114 很不耐烦的说已经查了三个电话了，直接转了机器报号。附近药店只卖药不处理伤口。打了一个多小时电话，终于有个电话能打通了。这几天没出小区就没做核算，也防止交叉感染。中日友好医院，给了三个方案：1. 120 直接能进，显然我神志清醒，不用这个 2. 去发热门诊，等着核酸结果，核酸结果出来不能走 3. 等核酸结果出来再看病，估计我也快失血过多了，要是昏倒在路边估计也没人搭理。没办法，硬着头皮打车去医院，于是挂号，门诊发了 N95，说我万一是阳性这就得关门了，没办法只能说拿人头担保。
发热门诊要求了核算和流感抗原，好说好商量下，门诊某大夫说已经通知外科大夫过来了，等了好久，外科那边只有一个大夫，说病人多，有空过来，于是问多久能过来，有没有给个时间什么的，回答是没有，体制里的托词，懂得都懂，看来要把我一直晒这了，没办法只能继续磨门诊大夫，反正门诊这人也不多。过了半个多小时，某大夫给写个了条，告诉我直接过去门诊外科就行。一瘸一拐找了半天路，敲开外科大夫的门，礼貌说着刚才的情况，外科科室 1 里面只有一个男大夫，大概四五十岁的样子，因为刚刚发热门诊大夫已经打过招呼了，于是简单说明情况，对方一副不耐烦的样子，哪个门诊？哪个某大夫？然后把我赶出诊室，没办法只能给门诊某大夫打电话，外科大夫在电话里跟某大夫说，意思病人没有持续性出血，有纱布包扎止血，等核酸结果吧。其实纱布是我自己出门简单包扎的，给大夫看伤口时，纱布往下掉了点，很多干的血迹，裤腿有点紧，还没掀到伤口那，大夫扭头就回诊室了，扔下一句，你这没有持续性出血，俨然一副趾高气扬的样子。我的腿还流着血，我也不知道还有没有命等核酸结果出来。于是质问他是不是今天今天我死在这你也拒诊。“是，我不能违反国家规定，没有 48 小时核酸不能进手术室”说完大夫扭头就进屋了，和他确认刚才说的话，他似乎也察觉到了说错了话，转过头就不认了，就说国家规定什么的。录音我会上报有关媒体，之前这样的事已经民怨载道了。保安凑过来了，目光盯着那个医生，我的腿还流着血，我尝试跟保安解释，这个医院是不能呆了，就没想好好给治，再来个公报私仇犯不上。估计大家都看新闻了，也没人出来拦着我。后悔当时没有直接报警。或者不讲中文用日语跟他们说。
我也是第一次有底气敢和人吵架，没想竟然在三甲医院。古语讲医门多疾。现在的医生不要求有医德，不要求跟病人好好说话，能把本质工作做好就可以去了，不要求不给开太贵的药。当然不是针对所有医院，仅仅用这个医生举例子，大家结合自己经历自行脑补就好。自疫情开始，多少人因为医院的政策问题被拒在门外，本人命大两次死里逃生，上次是打疫苗之后发烧 39 度，窗外下着暴雨打着雷，我要去治疗发烧却因为发烧不能看病。否则需要做抗原四项，一共 770。再等 4-6 小时出结果，期间不能离开，发烧 39 度在急诊那个环境呆半天估计是直接去另外的世界了。一年之内就遇到两起拒诊案件，其他人呢？因此去那个世界的人呢？和变相杀人有什么区别？不作为故意杀人罪可以进局子了吧。这种没有医德乃至道德的人直接革职查办，行政拘留吧。（不作为故意杀人：处死刑、无期徒刑或者十年以上有期徒刑;情节较轻的，处三年以上十年以下有期徒刑）
中日友好医院是压死骆驼的最后一根稻草，北京又如何，上海又如何？6 月 1 日，上海刚刚解封。6 月 2 日北京就重复上演这样的事情，把国家政策当挡箭牌，把百姓的命不当回事。自古有之敢冒天下之大不韪，杀伐决断，后来的人称之为任侠。古来救死扶伤，而今一个个伪君子，在其位不谋其事。
发文可能会被网暴，键盘侠从来不会关心你过的好不好，放心我不会自杀。不想做一个忍气吞声苟活于世的人，洪流之下，很多人都活成了龙啸云。
医院不是法外之地，还轮不到地方自己立规矩。
]]>网络越来越发达了，很多事情都可以在网上完成，学习外卖快递什么的比以前方便多了，甚至配眼镜也可以了。希望有一天可以在线吃饭吧。
先谈一下线上配眼镜的优缺点吧:
优点：
缺点：
几个月前被种草蔡司镜片，在蔡司睛选小程序上询问最普通的莲花膜也要上千，更何况我每天超过 10 小时面对电子屏幕，必须要蓝光膜，姑且不说是不是智商税，起码图个心里安慰，不要以为有蓝光膜就可以随便作了，眼睛病了也是病啊，就跟不好好吃饭等于慢性自杀一样。
找了几篇帖子，最终在 1688 上选择了一家深圳的眼镜店，我配的是钻立方的蓝光膜，应该是比较入门的一款镜片，毕竟第一次尝试，打算成功了后下一个眼镜直接上顶配。实测一周后发现，除了选镜框的时候没注意到尺寸有点小之外，其他的都算不错。基本流程就是，选镜框-验光-下单镜片-邮寄镜框-镜框加工。
镜框由于经费原因没有选择蔡司原厂，在京东上选了个商务风格纯钛材质了。品牌是精工，日本的老牌子了，眼镜店里的品牌在网上都搜不到，索性买了大品牌风格类似的。
京东下单，不过还需要调货，精工店比宝岛店还便宜一些。对这镜子试了试觉得风格挺好看就联系顺丰邮寄走
了，邮费 18 大洋。
后期收到货的是时候才发现同样的镜框，近视镜和平镜的感觉是不一样的，也可能是第一次用半框，总会看见边框。
验光是在宝岛眼镜，搜索公众号选择验光师就可以了(不要选配镜师)，之后的数据会同步到小程序上，验光的费用是 50,个人觉得还是挺划算的，毕竟一堆参数，验光师操作一堆设备操作起码半个小时，再加上我问了一堆问题。当然也不排除有些店嫌麻烦不提供验光服务的，去之前要电话沟通好。当然电话里说 50 一次然后去店里不给验光的也有。
如果想货比三家防止度数不准确的话，那么就不要去同一个连锁店了。毕竟他们都可以查到数据……
总之，宝岛还是挺靠谱的。
镜片根据需要下单就可以了，上边的加个是一片的，记得数量要选 2,然后还有加工费，算上这些差不多是线下的三分之一。加工之前卖家会确定下镜框和度数，剩下的就是加工时间和物流的时间了，顺丰发出。顺便吐槽下顺丰没有之前快了。
收到的第一感觉是轻，毕竟配眼镜成功的标准就是感觉不到它的存在。后来觉得我的树脂镜框就像一块石头压在了脑袋上。
除了天没亮剩下的都亮了的感觉。
保养的话，买了美的超声波清洗仪，190 入手。当然也可以洗假牙手表珠宝什么的。没有精力每天去洗，家里又多了一个长期吃灰的设备。
总体来看的话，还算挺成功的一次配镜。毕竟有句话叫做能用钱搞定的不要花是时间。懒人不止一次的为这个社会带来变革，希望有一天穷人也可以吧。
]]>●分解步骤——把技能做最大程度的细分，分成若干小步骤。
●充分学习——对每个小步骤进行充分学习，以便进行灵活的练
习，并在练习中自我纠正。
●克服困难——克服在练习中出现的生理、心理或者情绪上的障
碍。
●集中练习——至少用20小时集中学习最重要的小步骤。
了解你即将学习的技能是什么，探索研究，想想整
个过程，把技能细分为几个可以控制的小步骤。
训练、注意环境反馈，根据反馈调整方法。
不用怎么有意识地注意方法步骤就可以很自如地开展技能训练
如果你优先学习你感兴趣的事，那么你肯定花不了多少时间就能学成。
“集中精力，只学一门”对快速习得技能的重要性是不言而喻的。
当然，这并不意味着你把其他技能拒之门外，只是你暂时将之搁
置，等待未来重拾。
你的目标制定得越轻松，掌握相关技能的速度就越快。快速习得技能的目的并不是要尽善尽美，成为世界级大师，而是要在兼顾能力和效率的同时，快速提高
技能。
我们学习的大部分技能都需要细化步骤。当定下想学习的技能后，就该把这项技能细化为若干步骤。学会对步骤进行筛选。把关键的步骤先找出来，再集中时间和精力去学习。
对于某些技能而言，只有获得了必备工具，我们才可能最大限度地利用时间充分学习。
●训练前的准备工作。例如，训练前找不到工具放哪儿了；训练前
还没有选到合适的工具；忽略训练的必要条件。
●使用临时训练工具。例如，借别人的装备，也就是说，你使用的
器材是有时间限制的，随时会被要求归还。
●环境干扰。例如，开着的电视；突然响起的电话；刚刚收到的电
子邮件。
●情绪障碍。例如，害怕；怀疑；害羞。
腾出时间,建议你下决心保证20小时的训练量。一旦训练开始，就别停下来。如果中途卡住了，一定要坚持住，直到达到20小时这个初级训练目标。如果你没有毅力投入20小时，那么请你放弃。
快速反馈有助于快速习得技能。如果反馈及时或只有一点点延迟，我们会更容易把实际操作情况和目前所获得的结果联系起来加以分析，再做出适当的调整
初学一门新技能时，往往容易过分估计实际投入训练的时间。特别是当你状态不佳时，你会发现训练时间过得像蜗牛爬一样，慢慢吞吞。事实上，你实际训练的时间远没有自我感觉的时间那么长。你只需遵守一个规则：一旦计时开始，中途一定不能停下来。记住：在你练得有点泄气时，这个方法会让你更加轻松地完成更为持久的训练。
持续训练的时间越长，技能习得就越快。每天腾出时间做3~5次这样的分段计时训练，短时间内就会看到明显步。
刚开始习得新技能时，人们往往希望做得尽善尽美，但力求完美很容易让人产生挫败感。因为我们永远都不可能做到百分之百的完美。别去设想有完美的表现，保持良好状态的同时，保证训练量和训练速度才是最应该考虑的。练就一门技能必须用心，必须坚持。刚开始学习时，不要盲目追求质量，相反，必要的训练量和训练速度才是制胜法宝。练得多，练得快，才能学得快。
实践前，查阅一下和这门技能相关的信息是十分必要的。例如，
花20分钟的时间上上网、去书店或者去住所附近的图书馆找找
相关参考书和资料。总之，你应该想方设法地找到关于这门技能
的参考书（至少三本）、教学DVD、教学课本或者别的学习资料。
在早期研究中，参考资料里有很多让人疑惑不解的地方，有的是
概念，有的是方法，有的是理念。通常情况下，你很清楚它们的
重要性，可是你始终无法理解它们的意思。既无法理解为什么要
这么说，也无法理解为什么要这么做。别紧张，有困惑很正常。
不愿克服困难是影响技能习得快慢的主要因素。愚蠢的感觉的
确不好受，不过请你随时提醒自己：随着技能实践的不断深入，
你会慢慢解决这些疑惑，最终理解这门技能
不愿克服困难是影响技能习得快慢的主要因素。愚蠢的感觉的
确不好受，不过请你随时提醒自己：随着技能实践的不断深入，
你会慢慢解决这些疑惑，最终理解这门技能
学习新技能前，别去幻想你会学得多么完美。多设想一下最坏的
结局吧！
投入时间和精力学习新技能前，有必要和内行聊一聊。
这样我们可以提前预知技能训练的每个阶段会遇到的情况，从
而消除对技能学习的疑虑和误解，使我们在技能训练的过程中
不但不会灰心丧气，反而会更有兴趣坚持下去。
干扰因素越少，技能习得就越有效。
“间隔重复”是一个很好的记忆方法，它可以帮助我们定期且系统
地回顾所获取的知识和信息。对于那些记忆起来有难度的信息，
我们更要经常复习，而对于那些记忆起来相对简单的旧知识，我
们不必经常复习
推荐：Anki SuperMemo Smartr
大多数技能学习都有一套固定的模式：确定项目、着手准备、坚
持学习等。建立一套简单的定式可以让我们比较轻松地了解其
中的关键环节。罗列清单方便我们记住学习要点，使技能训练的流程更加系统
化，以便我们把精力投入到关键环节上。创建定式确保每次训练都有一套固定的模式。
预期测试是指依靠已知经验，在尝试实践前假设接下来会发生
的变化或者产生的结果。如果你养成了预期测试的习惯，那么你
学技能会更高效。科学地讲，预期测试结果随着以下四个因素的
变化而变化
●观察——你最近在关注什么？
●经历——你对这个领域了解多少？
●假设——怎样做会才会更进一步？
●测试——下一步你有什么新尝试？
我建议用一个笔记本或者其他的工具记录你在训练中做出的假
设。如果你不断思考这些假设，并且形成新的想法，那么你的实
验成果会更加丰硕。
我们的大脑和身体都处在各自的生理系统中，因此，它们都有生
理需求，比如食物、水、锻炼、休息、睡眠。我们不能把自己逼得
太紧，这样会适得其反。因为大脑和身体在没有足够能量储备的
情况下是不可能高效运转的
最佳学习周期是90分钟左右，在这个周期内，人的精力是最集中的。大脑和身体都
需要一个自然的休息。因此，我们要瞄准时机锻炼、休息、吃饭、
享用零食、打盹儿或做别的事情。
定期腾出时间练习，这就是练习的诀窍。
]]>按照时间间隔来衡量学习效果，每隔 25 分钟看学习了多少。
如果一件事可以在两分钟内完成，比如回复邮件，一个简单的家务，就立即完成，因为记住它、计划时间、在后来完成它，可能会花费五分钟甚至更多的时间。
拖延症是影响工作效率的大魁首之一，想要治愈它不是给自己定下目标、下定决心去完成一项大任务，而是只在那件事上花五分钟。你会发现在大多数情况下，它在超出五分钟的时候依旧很顺利，因为你已经进入了平坦期。
即使你是一个记忆天才，也要把每件事都从你的脑子里清理出来，并进行记录，方法不重要，可以把它们写在一个笔记本里，也可以放进专门的应用里等等。
在30分钟内只做手头上的事，不去理会其他任何事，没有电话、没有邮件、不说话、不看QQ消息提醒，除非发生火灾。当然，如果老板找你谈话例外，这是没办法的事。
睡眠少可能导致许多能力退化，不是危言耸听，美国军方研究表明，“每天少睡 1 小时持续一周会导致相当于 0.1 血醇水平的认知退化”。
《睡眠的秘密世界》指出：熬夜之后无论白天你干得有多好，情绪也不会太高。更重要的是前瞻性思考能力、行动的意愿、对冲动的抑制力、乐观程度、同理心、情商等也会下降。
所以，白天小睡真的是个好习惯，你没有发现爱熬夜的自己变笨了吗？
戴着耳机不一定在听音乐，这可以防止别人接近你、打扰你。有些人听音乐时工作效率更高，比如小编。
工作时把手机调成静音，放在眼睛看不到的地方，可以分批集中时间处理电话短信。
还有邮箱也一样，不用一直去关注，特别是放在早上和晚上处理，把需要解决的和代办事件列表连在一起，有用的存档，做到邮箱清零。
早上理出最重要的三件事，或是改成一件必做的，3件应该做的，或是五件可以做的，然后开始做最重要的一件事。不要认为意志力可以解决一切，把最重要的事情放在早晨做，并且尽可能地让所有事情自动化（委托，分批等等）。
你的大脑需要休息，并且有时候新一期的绿箭侠可以比最好的TED演讲创造更大的奇迹。
有时候假装无能能让你更有精力去展示自己的能力。
达尔豪斯大学的心理学教授 Simon Sherry 的完美主义与生产力研究发现，完美主义是生产力的绊脚石：
完美主义者完成任务需要花费更多的时间。
完美主义者因此等待完美时刻而耽搁。就商业而言，如果你等到了完美时刻时间已经太迟。
完美主义往往因为一叶障目而不见泰山，因为过于关注小事情而错失了大场面。
所以，真的，差不多就行了。
最后，还有一个方法就是把信用卡刷爆，当你觉得对工作不满意、没动力、效率不高时，去把你的信用卡刷爆，绝对鸡血满满，这个方法只为大家开心一下，要是这样还没动力：
“吃苦耐劳”真的是优良品质吗，与你怎么做相比，老板们应该更关心你做了什么、达到的效果。所以，效率，还是效率，希望这些实用小技巧对大家有所帮助。
]]>意志力像肌肉一样，是可以消耗的。
中国自古以来的耻感文化不利于自我救赎，会造成轻微的心理创伤，时间长容易患抑郁症，什么都不想干就是对当前的行为表示不满，并且没有更好的方法。
一个好的团体至关重要。
不要想一头粉色的大象，你的脑海里出现了什么呢？
允许自己就这样的活着。
]]>如果你的系统是稳定版的话，可能需要先降级回到开发版
You can use SD card or OTG USB as your image zip storage.
1 | adb device |
1 | adb reboot bootloader |
1 | fastboot flash recovery twrp.img |
after flash twrp rec
1 | fastboot reboot |
1 | fastboot flash recovery twrp-x.x.x-x-x.img |
2023 年 mokee 已经停更了
开水倒入不锈钢盆，放入冰箱，几分钟之后冰块就掉下来了
### 锅去顽渍
白醋和小苏打浸泡一会就可以擦掉了，注意铁锅不能用
### 玻璃水杯
尽量买双层的隔热杯，防止烫手，单层玻璃不管用。
]]>填饱肚子，和咖啡（减少疲劳感，专注时间会变长，150-200mg 咖啡因）
补充必要营养
① 增加有效的获得回报的预感。
② 减少无效的获得回报的预感。
影响注意力的因素（单调乏味，难度不对）
很多人会有如下误区，在众多的压力中，自责是伤害最大的。所以要自我接纳。
① 过分追求专注力。
② 过于责备自己没有专注力。
“先生，麻烦你跟我们走一趟”两个警察模样的人出现在他面前，冷冰冰的声音划破了这一沉寂。我们这位好好先生可是从来不问缘由的，更何况他觉得自己也没犯什错。甚至于老婆吵架时，他都是默默的承受着家庭暴力。
这次的目的地不是警察局，竟然是他的家里。屋中仿佛听见一男一女在吵架，女的似乎在咆哮：“看你昨天带回来的那个小男孩，再这么养下去我们都要穷死了！”男的成熟稳重，但也极富心机，他似乎都看不到那人的脸。那人说的每一句话都好似千斤：“我自有安排。”那个女人的声音听起来好像他的妻子，不过凭着他对她的相信，这一荒唐的想法很快就被否定了，哪怕他们只是新婚。就算新婚之夜他们刚刚吵了一架，他们也相信彼此都知道，两个人的完美主义还要慢慢磨合。世界上绝对没有任何人可以替代彼此的位置。本想等她气消了之后再和他一起游山玩水的。结果他发现现在像重物一样被人摔在地上，然后被拖进了一间黑屋子里。
清醒了一会，他发现这个屋子的布局竟然和他家一模一样，而且他也告诉自己，仅仅是相似而已。这个黑屋子很像是他的卧室，只不过没有了灯，整个屋子就好一间暗房。他瞪大眼睛似乎不敢相信这是真的。难道是谁要向他复仇吗？怎么选择了个这么相像的地方。他是个好好先生，但是也得罪过不少人。慢慢的，他发现这个屋子里还有其他人。角落里蹲着一个小男孩，目光有些呆滞，衣衫褴褛，头发也有些凌乱，而且无论他怎么喊，男孩就是不理他。男孩的周围，有一排排的月饼礼盒，上边贴满了个各种情绪的标签。走上前，他看见“智慧”和“勇气”，他曾经毫不犹豫的选择了前者，不过他觉得现在应该换个决定了。只不过男孩前面标有“自卑”与“抑郁”的盒子已经空了。“哎，今天可是中秋，看来今晚是很难见到月亮的了。”他自言自语道。
还好是中秋，月光可以透过这些黑暗，给每一间黑屋子带来光明。“喂，你看见前面那扇窗了吗？打开它，我们就可以出去了。”男孩仍然不理他，径直向前，甚至连头也不回。“终究还是孩子。”他一边叹着气，一边跟了过去。走了几步他就看见一个小女孩的骸骨横在前方，月光下显得格外阴森。而小男孩由于留恋外边的新鲜空气再也听不到他的声音了。就好像月光之下有塞壬的歌声似的。
他也不晓得为何清楚的记得过去了两周，大概是处于艰难险境的人对时间更为敏感吧。小男孩最终还是倒在了小女孩的身旁。“是我害了他。”不过这句话他没有说出口，因为他的身边已经没有其他人了。求生的欲望越来越强烈，回过头，门是虚掩这的，而且无论如何都无法反锁。他想过从这扇门中穿过去，只不过竟然有些怕那些人都聚集在门口，他一时间招架不住，于是还是选择跳窗。
不知道是已经没有退路还是求生的愿望过于强烈，拉开窗户，几个跟头，他就翻入了下一层。
虽然是高层，但是还是阴森森的像一个地下室。昏黄的灯光下边，照亮的几处蜘蛛网。他只有拼命的奔跑，只不过这里除了实验室还是实验室，难道这里住着一个和他一样的工作狂吗？他很清楚他这样很快就会被后边的人追上。“快过来这里，这里很安全！”走近细看，那人竟然是他的姑姑。他也来不及多想了。
暂时松了一口气，他瘫软在地上，余光扫过地面，一批批的黑影掠过。那她姑姑呢？为什么他可以随意走动？为什么她知道知道这里就是绝对安全的？为什么……难道？他不允许自己再这么想下去了。
“他就藏在这里。快点！”一个似曾相识的声音，十分钟之前是如何告诉自己这里是如何安全，现在有是如何把自己推向绝望的深渊的，当然这就是人性，他早就已经见惯，这次却疏忽大意。当然他终究是个理性的动物，抓紧门锁，外边向右转一圈，他就向左转一圈，累了就干脆锁死，就这样一直僵持着。
“无论如何我也要救我的孩子。”门外传来一阵叹息。
母亲受人驱使只是为了救子吗？他的心忽然颤了一下，他知道这种情况母爱是绝对不会讲道理的。他松开门锁，放弃了抵抗。
“你要用我来换你的孩子可以，但是我出去一定杀了你！”这话他是吼出去的。
“好！”对面毫不迟疑。
门开了。
里面走出了一个瞋目怒视的人 ，浑身散发着杀气，仿佛眼神都可以杀人。只有那个为了救儿子可以赔上性命的人还站在那里，似乎在等待最后的仲裁。现在两方都已经切身感受到，面对死亡本身就该无所畏惧。
随从的人早已经被吓破了胆，她还是义无反顾的站在那里，他死死的扼住她的咽喉，哪怕是他的长辈，哪怕帮助过他又马上背叛了他。这些他都不再想，因为他早已经被愤怒所淹没。他死死的攥住她的脖子，仿佛下一秒就能像向捏死一只蚂蚁一样捏死他。只不过，他突然松开了手。“带我去见他。你快点！”冷冰冰的语气，一点亲情的味道都没有了。她不回应，只是不停的咳嗽。
回到了之前的地方，之前的一男一女早已不见，地下只剩下一个破旧的书包，是他少年时期用过的，他解释不清楚。黑屋里走出个人影，正是先前日子倒下的小男孩，不同的是，他变得干净帅气又阳光。“是你救了我！”男孩嘴角上扬。
“我要去报警。你去自首？”这位好好先生第一次表现的这么富有攻击性。
去警局的路上，之前发生的一切好像都消失了，就连那件屋子也在慢慢的崩坏。
路的尽头，她的妻子在等着他，她也经历了同样的事。
她首先打破了这一宁静，“亲爱的我想写本书。”
“嗯？”
“你之前不是说过每个人走不出自己的世界吗？”
“那你这本书的名字就叫做《房间》好了。”
“这是一个主人格被邪恶人格囚禁的故事。”
“而且主人格终将获得胜利。”
他们彼此一次笑，又是黄昏，落日的石阶前，一切坎坷都被照的透亮。
]]>以至于到了日俄监狱，那份恐惧仍旧没有消失。高高厚厚的城墙，勾起了几年前途经伪皇宫的回忆，如果说高城壁垒是为了防止犯人逃窜，那么皇宫岂不是帝王将相的牢狱？这样想着，愿生生世世莫生于帝王之家倒是一种悲哀的绝唱了。
事实上，穿过城墙，里面并没有想象中的庄严，本以为这里的冤气会压迫灵魂，让人窒息，事实上是，一路惊魂未定，却连一丝血腥气都未曾嗅到过。
监狱明显翻新过，若是复古风格，经历过枪林弹雨的山石和被抓破了的淋满殷红的墙壁才与它相称。角落里卧着的一口大钟倒是引人注意，介绍上说，这是日本帝国主义卑劣行径的体现，过去每天都有僧人到这里来超度，借以来消磨人们的反抗意志。看到这里我无意为日本开脱，若是余生充满痛苦，透过佛法来看世界倒是一个不错的选择。佛教从古印度传到中国，日本，最后成为世界三大宗教之一，自然是可以为大众消灾解祸的。这里仅仅表明立场，不做任何评价。
不过倒是想起了关于安倍的一则新闻，安倍夫妇通过初等教育渗透“爱国主义思想”，那么这些东西就像一种信仰，正在这些孩子们大脑中根深蒂固，那么与宗教，还有我们从小被培养的抗日情怀，其实都是同样一种意识形态。
整个监狱不大，猜测犯人不足一千，里面有很多过去工厂的牌坊，现在一些关闭，一些则摆放一些遗物供人们参观。大概以前犯人们就都在这里劳作。还有医务室，对于重症的病人，当然安安静静的等待他们死去。因为在这里最便宜的就是人命，人命是换取劳动果实的易耗品，当然也是供这里的人取乐的工具。把犯人双眼用黑布蒙上，让其跪在地板上，然后把脖子套进绳索，再把木板抽走，人就掉在了几米之下的木桶里，然后被几个同伴默默地抬起奔赴坟场，狱卒在后面举着短枪，准备随时扣下扳机。
复原图倒是有几具骷髅，混着朽木和尘土。当然我十年前在黑龙江省博物馆便见过真实的骨架，除了不理解为什么手心那里是凹下去的，其余并没有什么意外。小时候也埋葬过燕子，所以对骨头并不怎么畏惧，也不觉得好端端的一个人忽然变成一堆白骨有什么奇怪的地方。那个年代，人命真的是不值钱的，有些人终其一生不过吃了几颗枪子而已。
那么与那时相比，我们是否更加幸运？当然是否定的。那时的冲突是意识形态，现在则是文化断层。我们是否要缅怀先烈？那也不必，这种历史不会再重演。若是生在战争年代，那么终生梦想便是世界和平，人生安稳。现在一定与那时不一样。有人说历史一共分为三种：第一种是已经逝去的岁月，往事不可追忆；第二种写在了各类史诗典籍中，可能迫于当时时局，略加修改；那么第三种便是自己阅读各类典籍，加上自己的心得体会，认为历史应当是这个样子。那么历史是不必躺在水晶棺中任人观赏的了。与华丽相比，应该更接近于真实。
那么现在中日关系如何？我们作为小人物当然不想太清楚。国际上有一条交友准则，没有永恒的朋友，只有永恒的利益。从旅顺回到大连，写下了这样的话：
旅大是日本的情妇，被百般虐待，所有的灵感都来源于她，荣誉则是成为一份作品，而毁灭也恰好是她。
]]>
1、前1、2位数字表示：所在省份的代码。
2、前3、4位数字表示：所在城市的代码。
3、前5、6位数字表示：所在区县的代码。
4、第7～14位数字表示：出生年、月、日，7、8、9、10位是年，11、12位是月，13、14位是日。
5、第15、16位数字表示:所在地的派出所的代码。
6、第17位数字表示性别:奇数表示男性，偶数表示女性。
7、第18位数字是校检码:校检码可以是0～9的数字，有时也用X表示。
8、＊尾号X是作为尾号的校检码，是由号码编制单位。X是罗马数字的10，用X来代替10，可以保证公民身份证符合国家标准。
]]>在 U 盘、SSD 等固态存储产品中，闪存芯片颗粒是核心，其关乎产品成本、寿命以及速度。闪存芯片颗粒主要有三种类型，分别为 SLC、MLC、TLC，三者之间的区别，如下。
SLC = Single-Level Cell
，即 1bit/cell，速度快寿命长，价格贵（约 MLC 3 倍以上的价格），约 10 万次擦写寿命；
MLC = Multi-Level
Cell，即 2bit/cell，速度一般寿命一般，价格一般，约 3000—10000 次擦写寿命
TLC =Trinary-Level Cell，即 3bit/cell，也有 Flash 厂家叫 8LC，速度慢寿命短，价格便宜，约 500-1000 次擦写寿命。
intel 傲腾 900P 固态硬盘是英特尔针对商业客户和游戏发烧友推出高性能 SSD，它使用的就是 SLC 闪存颗粒，
持续写入速度 2.0G/S，4K 写入 50 万 IOPS；
持续读取速度 2.4G/S，4K 读取 55 万 IOPS；
寿命约为全盘写入 15000 次，每天全盘写入一次，预估寿命为 40 年；
SLC 闪存颗粒就像这款搭载它的傲腾 900P 一样，尽管已经是“宇宙级最强 SSD”了，但因为贵，所以销量惨淡！
三星 960 Pro 是三星针对游戏发烧友和专业级用户推出的高性能 SSD，它使用的是 MLC 闪存颗粒，
持续写入速度是 2.0G/S,4K 写入 33 万 IOPS;
持续读取速度是 3.2G/S，4K 读取 33 万 IOPS；
寿命约为全盘写入 1500 次，每天全盘写入一次，预估寿命为 4 年；
对普通人用户来说，SLC 颗粒就像劳斯莱斯幻影，好是好，但是太贵，所以，极少有人买；MLC 颗粒就像宝马 7 系，车还算可以，但还是贵，买的人还是少；
只有 TLC 颗粒就像福克斯，虽然性能和品质远不如劳斯莱斯和宝马 730，但是价格实惠，所以，买的人最多；
三星针对消费级市场推出的廉价版 SSD，虽然它采用了速度最慢的 TLC 闪存颗粒，但因为它使用了 PCIE3.0*4 通道作为数据传输通道，所以，它的读取速度还是甩了所有 SATA 接口 SSD 几条街；
三星 960EVO 持续写入速度为 1.5G/S，4K 写入 30 万 IOPS；
持续读取速度为 3.2G/S，4K 读取 33 万 IOPS；
寿命约为全盘写入 700 次，每天全盘写入 1 次，预估寿命为 2 年；
当然，普通用户根本没有那么大的写入数据需求，以每天 20G 的数据写入量，即便是寿命最短的三星 960EVO，预期寿命也有 20 年；
最后，我想说，以普通用户的日常数据处理量，TCL 闪存颗粒肯定够用了，没有必要去追求什么 SLC、MLC；我们只要性价比，我突然发现一个事实：目前某东上热销的 SSD 都是 TLC 固态！
]]>| 步骤顺序 | 步骤名称 | 预计耗时 | 说明与正念要点 |
|---|---|---|---|
| ① | 轻醒 & 伸展 | 2 分钟 | 闹钟响后深呼吸 3 次，慢慢伸展四肢，感受身体苏醒。倒热水 |
| ② | 整理床铺 | 2 分钟 | 拉平被子、摆正枕头，专注手部触感和动作节奏。 |
| ③ | 洗漱 & 冷暖唤醒 | 5 分钟 | 刷牙、洗脸时专注水流和泡沫触感，最后用凉水拍脸 2–3 次。 |
| ④ | 补水 & 接触自然 | 3 分钟 | 喝温水（可加柠檬），打开窗户感受空气与光线。 |
| ⑤ | 正念冥想 | 10–20 分钟 | 正念练习 + 记录 |
| ⑥ | 今日启动 | 5 分钟 | 写下 3 件最重要的事，看镜子微笑，对自己说“我准备好了”。 |