甲辰年度总结

时光荏苒,岁月穿梭,又是一年过去了,在这里祝各位新年快乐。 今年发生很多事情,写这篇文章的时候还有半个小时就要到乙巳年了,原本躺在沙发上拿春晚当背景音乐,刷着抖音,但是突然意识到今年的年度总结还没写……. 等这篇文章发布的时候,估计已经到乙巳年了,再一次的祝大家新年快乐、阖家幸福、身体健康、一夜暴富!!!!!!!! 生活 今年的生活,一直过着枯燥的学习生活,但是和去年的不同的是获得了一些小惊喜、拿到了喜欢的域名、为自己的职业选择好了方向,而且收益还不错。 还要说一句,感觉自己的拖延症也越来越严重了,而且体重直线飙升,要有所改变了。 域名 这应该是我今年最开心的一件事情了。 看我文章比较早的朋友应该知道,我的博客更换过很多域名,最开始用的是 roy.pub 后面又换过很多域名,比如我之前持有的 roywang.cn 这个域名一直续费到现在,后面拿到了 roy.wang 这个 Hack。 原本以为到这里就可以心满意足了,但是从去年开始,心里就痒痒的,既然 Hack、cn都有了,就没有什么不能拿下com 呢,所以从去年就开始的接触 com。 通过 web.archive.org 可以看到,roywang.com 这个域名之前是被一家专业的域名销售公司所持有的,挂价 $2288。自从去年尝试接触询价过一次,但是回答我的价格是 $500 ,但是觉得这个价格觉得很贵,所以就没有回复,就这样沉寂了下去。 中间一度这个域名快到了赎回期,结果又续费了。这让我很难受,紧接着这 roywang.net 也过期了,之前这个域名是一名设计师所持有的,不知道为什么,不再续费了。但是后面的拍卖的价格也到了接近 $100 ,所以也没拿。 快要考研的日子了,不知道为什么,或许是几个朋友的教唆,一狠狠心拿下了 roywang.com,但是一毛钱都没砍下来,只能含泪花了 $500 拿下了这个域名,我想这样应该就没有什么域名能让我心动了。 现在这个域名被我备案,拿来放个人主页,还有一些静态资源的加速,写这篇文章的时候才发现,在完成服务迁移之后,博客的图片竟然没有替换链接…..可能是博客流量太低了,竟然一条提醒都没收到,哭了/(ㄒoㄒ)/~~ 最后我要说一句,我恨王源!!!!!!!!!!!! 职业 在去年的11月,小金库逐渐见底,所以就去闲鱼挂了个链接,看看能不能赚点生活费。 让我惊喜的是,竟然接到了一些还不错的单子,收入还不错,所以让我坚定了信心,以后就做独立开发了, 初期之后解决一些服务器上的小问题,或者帮助别人部署些东西,做些简单的二次开发。逐渐接近了考试的日期,闲鱼那边就没有再去管过了。 但在考完最后一场,回家的路上,想着休息几天,之后再接着做一下,接点单子搞点钱,过年嘛。但当我登录闲鱼之后突然发现自己的链接竟然被举报下架了……….. 虽说如此,突然意识到我还挺喜欢干这个的,时间自由,想干就干,收入还可以,能到预期的水平,要不然以我的学历,也就去个外包,一个月五六千, 每天朝九晚不定的。还要接受老板的PUA和画饼,综合看下来,还不如自己做独立开发…….. 如果上不了岸,就做这个吧,虽然收入不算高,好在时间自由,完全是为自己做的(有需要的老板也可以联系我)。 博客 去年一共发布了6篇文章,但刨去年度总结,只有五篇文章,没有做到一月一篇,很难受…….这也是我拖延症的体现……. 流量 刚才才去看了自己博客在去年的流量,只能说用 惨不忍睹四个字去形容: 这个数据已经不忍心看了…….就不分析了。 流量最高的是 《CentOS7 升级 Glibc 2.17 到2.28》,紧跟其后的是《CloudFlare 解决 CORS 跨域问题》。 去年寄大希望的 AuthenTik 的相关文章一个进前10的都没有,反而开源的一个域名监控程序,浏览量进入了前五。 关于来源网站,不出去年的所料,现在百度的来源已经掉光了,去年还有8.01K,今年只剩下了1.21K,这或许可能是博客流量表现不佳的原因之一,不一定是我的问题~ 但是今年谷歌和bing的流量有些许增加。dalao论坛,还有v2ex成功进入前十。 今年 去年一年,无论博客的更新,还有学习、生活都是平平无奇的一年。 唯一让我开心的是就是自己人生的方向,已经找到,而且拿到了心心念念的域名。 去年的定下的目标完成的就只剩下一个学习了,但是还有一个月才能检阅一下学习完成的怎么样,所以姑且算完成了一个,但是关于月更博客嘛还有减肥嘛…..完全可以当作今年的目标! 虽然心有遗憾,但今年还是有些小惊喜,按照惯例还是定个乙巳年的目标,到明年的除夕夜回顾起来看看完成了多少。 乙巳年就四大个目标: 月更博客:月更一篇我个人满意,尽量高质量的文章。 学习:接着努力学习,不管有没有上岸、争取今年能够看完40本书。并且分享下读书的感悟。 减肥:现在的体重已经200了,不能再胖下去了,现在已经明显感觉到了某些方面力不从心,而且半夜睡觉呼吸都会被自己憋醒。目标回到150吧,对于我来说应该不算太高的难度。 努力挣钱:如果不能上岸的话,就努力搞钱吧,这是今年最重要的一个目标,给来点保障。 这次狠狠心,前三个里面,如果有一个没完成,到下一个除夕夜,就给朋友们发1000的红包,如果三个没完成就3000块。 我打算开始月更一篇生活文章,看看这个月干了什么、有什么惊喜、减肥的进度如何、看了什么书,写写体验,当作日记来写,这已经不能叫日记了,应该叫月记。 如果有希望共同进步的朋友也可以联系我一下,互相学习,互相进步! 那就这样,让我们丙马年再见。

2025/1/30
articleCard.readMore

使用 AuthenTik 的一些问题,以及服务不验证身份路径配置

原本打算将这个文章分成三篇来水的,但是发现如果分成三篇文章,篇幅有些太短,还是一篇出来吧。这篇文章主要介绍三个方面: 使用 Nginx 正向身份验证,出现 500 错误 正向身份验证 不验证路径性能差 部分服务不验证路径配置 其中两个问题,一个参考配置。说实话折腾了很久,搜烂了百度还是谷歌都没找到具体的解决方案。但后来还是通过 GPT 通过遍历法,才解决了其中的两个问题。 使用 Nginx 正向身份验证,出现 500 错误 如果你看了我之前的 《AuthenTik - 开源的身份验证服务》的话,在文章的最后预告了这篇文章。 当你无论是使用官方文档里的配置,还是配置应用程序完成之后 AuthenTik 给出你的配置,如果将验证的请求地址设置为公网地址,对不起,它就会发生 500 Error,反而配置为内网的 IP 就不会出现这个问题。 在此之前,你需要检查一下是否为该应用添加到前哨之中,并且尝试将 Nginx 配置文件中的外部的 AuthenTik 服务地址更换为 内网IP,如果使用内网IP并未出现这个问题,那么恭喜你,这个方法很可能就能解决你的问题。 检查日志的时候并不难发现,当你访问需要前置验证的地址时,Nginx 并没有没有访问正确的 AuthenTik 的服务地址: https://123.123.123.123/outpost.goauthentik.io/auth/nginx 因为配置了 HTTPS 所有服务都走的是 443 端口(反向代理),而一台服务器不可能仅仅只配置一个服务,最最重要的是并没有告诉服务器,你需要访问的是哪个服务,所以就造成了这种错误。 解决方法 解决方法也非常简单,在监听/outpost.goauthentik.io路径中,将Host替换为 X-Forwarded-Host 头即可。 location /outpost.goauthentik.io { # When using the embedded outpost, use: proxy_pass https://sso.home.roywang.cn/outpost.goauthentik.io; # For manual outpost deployments: # proxy_pass http://outpost.company:9000; # Note: ensure the Host header matches your external authentik URL: # proxy_set_header Host $host; 原本文档自带的。 proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie $upstream_http_set_cookie; proxy_pass_request_body off; proxy_set_header Content-Length ""; } 官方的文档中默认 AuthenTik 独占了一个端口,所以并没有考虑 X-Forwarded-Host 头,导致 Nginx 访问直接通过 IP 进行访问了 AuthenTik 服务,而我们配置了反向代理,这肯定是访问不到的。 特别注意: 而如果直接添加X-Forwarded-Host头,与proxy_set_header Host $host共存也会导致这个错误。 添加后即解决了这个问题。 正向身份验证 不验证路径性能差 由于我的一些文档都是通过WebDAV协议进行同步的。但是部署完正向身份验证后,有些时候同部文件的时候会出现超时错误,看了下 GoodSync,同步时间翻了 10 倍。经过实验确定是 AuthenTik 的性能问题。 其实看一下对比,390个文件、463个文件夹,这是使用了 AuthenTik 的不验证路径配置的性能: 172238 变更:0, 冲突:0, 复制时间:0, 复制状态:0, 错误: 0, All: 882 172238 -- 分析已结束。历时 00:02:16, 速度: 53 文件/秒 这是不使用 AuthenTik 的不验证路径配置的性能: 172338 变更:0, 冲突:0, 复制时间:0, 复制状态:0, 错误: 0, All: 882 172338 -- 分析已结束。历时 00:00:14, 速度: 61 文件/秒 其实解决方法也很简单,就是通过 Nginx 接管这部分 URI,不去走 AuthenTik。 具体的配置会在下面给出,但是需要说明的是,有些服务的 URI 是不固定的,只能通过 AuthenTik 的正则去匹配(比如 Gitea) 部分服务不验证路径(放行 URI )配置 这一部分介绍一些服务的 API 路径的配置,毕竟如果 API 还需要验证,很多服务就失去了它的意义。 有些服务有些特殊,比如 Gitea。就像前面所说,在使用 git 命令时,中间有一段 URI 是仓库名,而 Nginx 是无法匹配相关的 URI 的,只能使用 AuthenTik 的正则去匹配,虽然性能有些差,但是勉强能用,体感不会像 Alist 的 WebDAV 的差距那么巨大。 AuthenTik 不验证路径正则配置 Gitea 开始就是给出 Gitea 服务的正则,这是我使用的服务中唯一使用 AuthenTik 正则去配置不验证路径的。 这套正则,在使用 git 命令时,是完全没问题的,但其他方面没有测试。 ^/api/.*$ ^/[^/]+/[^/]+\.git/info/refs$ ^/[^/]+/[^/]+\.git/git-receive-pack$ ^/[^/]+/[^/]+\.git/git-upload-pack$ Nginx 不验证路径配置 主要还是监听相关路径,配置auth_request off;取消对于该路径的验证,然后去反代相关目录。 Alist WebDAV location /dav/ { auth_request off; proxy_pass http://127.0.0.1:12345/dav/; proxy_set_header Host $host; } Vaultwarden(Bitwarden) location /api/ { auth_request off; proxy_pass https://127.0.0.1:12345/api/; proxy_set_header Host $host; } location /icons/ { auth_request off; proxy_pass https://127.0.0.1:12345/icons/; proxy_set_header Host $host; } location /identity/connect/token { auth_request off; proxy_pass https://127.0.0.1:12345/identity/connect/token; proxy_set_header Host $host; } location /identity/accounts/prelogin { auth_request off; proxy_pass https://127.0.0.1:12345/identity/accounts/prelogin; proxy_set_header Host $host; } Navidrome location /rest/ { auth_request off; proxy_pass https://127.0.0.1:12345/rest/; proxy_set_header Host $host; } location /api/ { auth_request off; proxy_pass https://127.0.0.1:12345/api/; proxy_set_header Host $host; } location /auth/ { auth_request off; proxy_pass https://127.0.0.1:12345/auth/; proxy_set_header Host $host; } Memos location /api/v1/ { auth_request off; proxy_pass https://127.0.0.1:12345/api/v1/; proxy_set_header Host $host; } WireGuard DoH 使用X-Forwarded-For头替换掉Host可以保证 Docker 部署的 WireGuard DoH 正确的获取客户IP。 location /private-doh-service/code-01 { auth_request off; proxy_pass https://127.0.0.1:12345/dns-query/code-01; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } Artalk 使用X-Forwarded-For头替换掉Host可以保证 Docker 部署的 Artalk 正确的获取客户IP。 location /api/ { auth_request off; proxy_pass http://127.0.0.1:12345/api/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /sidebar/ { auth_request off; proxy_pass http://127.0.0.1:12345/sidebar/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /static/images { auth_request off; proxy_pass http://127.0.0.1:12345/static/images; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } Umami 使用X-Forwarded-For头替换掉Host可以保证 Docker 部署的 Umami 正确的获取客户IP。 location /api { auth_request off; proxy_pass http://127.0.0.1:12345/api; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } 后语 这篇文章规划了一个多月了,但是一直没时间写,终于抽空写了出来。 关于一些服务的不验证 URI 配置,可能在使用中在某些方面出现一些问题,如果有问题可以在评论区留言。或者有些别的服务,我这里没有列出的,也可以留言,我会尽力回答。

2024/10/12
articleCard.readMore

Puff - 开源的域名监控工具

昨天早上在群里吹水,关注的一个域名橘子已经回复会删除了,但多久删除没有底,想问问群里的大佬多久会删除,但是问了一圈都不知道,所以萌生了写一个域名监控的想法。 目前这个服务呢,仅支持监控域名掉落,不能负责抢注,但抢注更多的不是技术难题,而是别的方面。后续打算增加一个域名动态检测的功能,如果域名过期了、进入赎回期、待删除之类的,都可以提醒一下(已支持)。 如果大佬们有更好的建议,可以给我留言一下。 2024-10-1更新,增加了几个新功能: 增加域名进入赎回期、待删除之类的通知。 登录会话两小时超时。 增加个Logo 修复了几个 BUG Puff 项目地址:Puff 开源、快速、便捷、基于Go的域名监控程序。 特性 性能优秀 基于 Go 语言开发,快速且性能优秀! 易于使用 部署简单,支持不同平台的多种部署方式。 提供了一个用户友好的界面和直观的操作流程,使得即使是初学者也能轻松上手。 UI 现代化 不知道怎么吹了………….. 部署 Puff 目前支持三种部署方式,编译部署、手动部署、Docker 部署。 编译部署 环境要求 Go 版本 >=1.22.0 克隆仓库 git clone https://github.com/bitaur/puff.git 构建程序 go build -o Puff.exe main.go 运行 ./Puff 手动部署 下载 Puff 打开 Puff Release 下载对应的平台以及系统的文件。 如果最新的包没有您对应的二进制文件,可以提交 issues ,或可以选择自己编译安装。 其中: armv6 对应 arm 架构32位版本,arm64 对应 arm 架构64位版本。 x86 对应 x86 平台32位版本,x86_64 对应 x86 平台64位版本。 克隆模板文件以及静态资源文件。 手动运行 Linux / MacOS # 解压下载后的文件,请求改为您下载的文件名 tar -zxvf filename.tar.gz # 授予执行权限 chmod +x Puff ./Puff Windows 双击运行即可。 持久化运行 Linux 使用编辑器编辑 /usr/lib/systemd/system/puff.service 添加如下内容: [Unit] Description=puff After=network.target [Service] Type=simple WorkingDirectory=puff_path ExecStart=puff_path/Puff Restart=on-failure [Install] WantedBy=multi-user.target 保存后,使用 systemctl deamon-reload 重载配置。具体使用命令如下: 启动: systemctl start puff 关闭: systemctl stop puff 配置开机自启: systemctl enable puff 取消开机自启: systemctl disable puff 状态: systemctl status puff 重启: systemctl restart puff 更新版本 如果有新版本更新,下载新版本,将旧版本的文件删除即可。 Docker 部署 首先请确保您正确的安装并配置了 Docker 以及 Docker Compose Docker CLI docker run -d --restart=unless-stopped -v /data/puff:/app/data -p 8080:8080 --name="Puff" bitaur/puff:latest Docker Compose 在空目录中创建 docker-compose.yaml 文件,将下列内容保存。 services: Puff: image: bitaur/puff:latest container_name: Puff volumes: - /data/puff:/app/data restart: unless-stopped ports: - 8080:8080 保存后,使用 docker compose up -d 创建并启动容器。 Docker 容器更新 CLI #查看容器ID docker ps -a #停止容器 docker stop ID #删除容器 docker rm ID #获取新镜像 docker pull bitaur/puff:latest # 输入安装命令 docker run -d --restart=unless-stopped -v /data/puff:/app/data -p 8080:8080 --name="Puff" bitaur/puff:latest Docker Compose #获取新镜像 docker pull bitaur/puff:latest #创建并启动容器 docker compose up -d 访问 此时打开 localhost:8080 即可打开站点。默认账号密码均为 admin。 后语 这东西写的很快,其实也没什么难度,但是就是没有看到啥开源项目,具体的使用就不多介绍了,基本上就是一看就会。 如果有什么功能需求,也可以在评论区留言一下,如果是不错的提议,我会考虑更新给软件加上!

2024/9/28
articleCard.readMore

AuthenTik - 开源的身份验证服务

一直以来都想部署一个前置验证的服务,作为前置验证的网关(类似于Nginx Auth),用来保护一些开放于公网上但自用的服务。但 Nginx Auth 太过简单(丑),虽想着找到一个能够满足我的这些功能的一个身份验证服务,经过 @Shell 的安利,选择了 AuthenTik。 选择 AuthenTik 最主要的原因是因为其 UI 讨喜,另一个便是使用的人相对较多而且也在积极维护。但中文互联网上有关于 AuthenTik 的内容不多。 每次访问同一域名下的某个服务时,都会先跳转到 AuthenTik 的认证页面,认证成功后,才会跳转到服务本来的页面。在某一时间内访问同一域名下的其他服务时,则不需要认证,不仅加强了安全性,还保护了隐私。 AuthenTik 不仅可以作为 IdP 进行使用,更多的人是将其作为 SSO 进行使用,一个站点登录,即可于同域名下的其他自建服务进行免登录操作。 AuthenTik 项目地址:AuthenTik AuthenTik 是一个 IdP(身份提供商)和 SSO(单点登录),其每段代码、每个功能都以安全性为首要构建,并强调灵活性和多功能性。 借助 AuthenTik,网站管理员、应用程序开发人员和安全工程师几乎可以在任何类型的环境中获得可靠且安全的身份验证解决方案。它为用户和应用程序提供了强大的恢复操作,包括用户配置文件和密码管理。您可以快速编辑、停用甚至模拟用户配置文件,并为新用户设置新密码或重置现有密码。 您可以在现有环境中使用 AuthenTik 来添加对新协议的支持,因此将 AuthenTik 引入您当前的技术堆栈不会带来重新架构的挑战。我们支持所有主要提供商,例如 OAuth2、SAML、LDAP 和 SCIM,因此您可以为每个应用程序选择所需的协议。 特性 管理界面:用于创建和管理用户和组、令牌和凭据、应用程序集成、事件以及定义标准和可自定义登录和身份验证流程的流程的可视化工具。易于阅读的可视化仪表板显示系统状态、最近的登录和身份验证事件以及应用程序使用情况。 用户界面:AuthenTik 中的控制台视图显示您已实施 AuthenTik 的所有应用程序和集成。单击要访问的应用程序以将其打开,或向下钻取以在管理界面中编辑其配置。 流程:流程是登录和身份验证过程的各个阶段发生的步骤。阶段代表登录过程中的单个验证或逻辑步骤。AuthenTik 允许自定义和精确定义这些流程。 配置要求 2个 CPU 核心 2 GB RAM 环境需求 Docker Docker Compose(建议使用 Compose v3) 部署 AuthenTik 此处推荐,且仅演示使用 Docker 进行部署。 配置 ENV 文件 全新安装 Authentik 首先需要生成 .env 文件,并向文件中写入生成的密钥以及密码。 echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env 建议开启电子邮件通知,如果系统有安全性以及功能性的更新,可以及时收到更新通知的邮件,将下列配置写入 .env文件。 如果长时间未能接收到邮箱,请查看开启的 TLS 或 SSL 加密对应的端口号是否填写正确!且 TLS 与 SSL 不可同时开启。 TLS:587 SSL:465 但是经过我实测发现,QQ 邮箱通过 SSL 进行加密会导致发信失败,使用 TLS 则一切正常,但据我推测,这个问题很可能是 AuthenTik 的 bug。 # SMTP 主机地址及端口号 AUTHENTIK_EMAIL__HOST=localhost AUTHENTIK_EMAIL__PORT=25 # 邮箱服务的账号以及密码 AUTHENTIK_EMAIL__USERNAME=roywang AUTHENTIK_EMAIL__PASSWORD=roywang # 开启 TLS,与 SSL 不可同时开启。 AUTHENTIK_EMAIL__USE_TLS=false # 开启 SSL,与 TLS 不可同时开启。 AUTHENTIK_EMAIL__USE_SSL=false AUTHENTIK_EMAIL__TIMEOUT=10 # 邮箱地址 AUTHENTIK_EMAIL__FROM=authentik@localhost 可选的其他配置 # 配置服务所使用的端口 COMPOSE_PORT_HTTP=80 COMPOSE_PORT_HTTPS=443 # 启用错误报告 AUTHENTIK_ERROR_REPORTING__ENABLED=true Docker 部署 将以下内容保存为docker-compose.yml文件,将其与上步中.env文件放于同一目录。 请注意,其中需要修改的各处。 services: postgresql: image: docker.io/library/postgres:16-alpine container_name: Authentik-Postgresql restart: unless-stopped healthcheck: test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"] start_period: 20s interval: 30s retries: 5 timeout: 5s volumes: //PgSQL数据存放目录,此处需要修改。 - /your-authentik-path/postgresql:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: ${PG_PASS:?database password required} POSTGRES_USER: ${PG_USER:-authentik} POSTGRES_DB: ${PG_DB:-authentik} env_file: - .env redis: image: docker.io/library/redis:alpine container_name: Authentik-Redis command: --save 60 1 --loglevel warning restart: unless-stopped healthcheck: test: ["CMD-SHELL", "redis-cli ping | grep PONG"] start_period: 20s interval: 30s retries: 5 timeout: 3s volumes: //Redis缓存存放目录,此处需要修改。 - /your-authentik-path/redis:/data server: image: ${AUTHENTIK_IMAGE:-docker.io/beryju/authentik}:${AUTHENTIK_TAG:-latest} restart: unless-stopped container_name: Authentik-Server command: server environment: AUTHENTIK_REDIS__HOST: redis AUTHENTIK_POSTGRESQL__HOST: postgresql AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik} AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik} AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS} volumes: //AuthenTik数据存放目录,此处需要修改。 - /your-authentik-path/media:/media - /your-authentik-path/custom-templates:/templates env_file: - .env ports: - "9443:9443" depends_on: - postgresql - redis worker: image: ${AUTHENTIK_IMAGE:-docker.io/beryju/authentik}:${AUTHENTIK_TAG:-latest} restart: unless-stopped container_name: Authentik-Worker command: worker environment: AUTHENTIK_REDIS__HOST: redis AUTHENTIK_POSTGRESQL__HOST: postgresql AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik} AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik} AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS} user: root volumes: - /var/run/docker.sock:/var/run/docker.sock //AuthenTik 数据存放目录,此处需要修改。 - /your-authentik-path/media:/media - /your-authentik-path/certs:/certs - /your-authentik-path/custom-templates:/templates env_file: - .env depends_on: - postgresql - redis 此时运行 docker compose up -d启动容器,官方默认的docker-compose.yml 的文件中,Server以及Worker均使用的是 ghcr,国内服务器根本拉不到镜像。 待容器均已创建启动完毕,初始化设置时需访问: https://your-ip:9443/if/flow/initial-setup 默认用户名为akadmin。 使用 在此主要是介绍一下如何给服务添加验证。 OIDC 如果需要通过 OIDC 接入 SSO,可以参考 Shell 的博客: https://blog.ning.moe/tags/Authentik/ 正向代理 首先需要进入管理员页面。 创建提供程序 进入管理页面后,左侧菜单栏依次点击应用程序-提供程序,点击创建,选择Proxy Provider。 然后点击下一步,在此处分别输入程序名称,选择身份验证流程、授权流程(默认选择第一个即可),然后选择Forward Auth(单应用) 在下方输入外部主机,也就是服务的域名(需要带 http or https 协议头)以及设置令牌有效期。 高级设置 证书选择,可做作用域全选。 不验证身份的路径,有些服务还会向外提供 API,这个验证路径就是为该部分服务准备的。使用的 Go 语言正则。但是这个不建议使用,有较为严重的性能问题。 具体解决方案可以期待后续文章。 创建应用程序 位于左侧菜单栏应用程序-应用程序,点击创建。 输入名称以及Slug,选择刚刚创建的提供程序。策略引擎模式 选择 all 添加前哨 位于左侧菜单栏应用程序-前哨,右侧的操作选择编辑,选择已有的应用程序,将其添加至右侧,点击更新。 Nginx 配置文件 因为是正向代理,所以需要修改一下 Nginx 的配置文件,此配置通用。 在配置文件最上部添加: # Upgrade WebSocket if requested, otherwise use keepalive map $http_upgrade $connection_upgrade_keepalive { default upgrade; '' ''; } 在监听的根目录下location /{}中添加配置: proxy_pass $forward_scheme://$server:$port; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade_keepalive; auth_request /outpost.goauthentik.io/auth/nginx; error_page 401 = @goauthentik_proxy_signin; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; auth_request_set $authentik_username $upstream_http_x_authentik_username; auth_request_set $authentik_groups $upstream_http_x_authentik_groups; auth_request_set $authentik_email $upstream_http_x_authentik_email; auth_request_set $authentik_name $upstream_http_x_authentik_name; auth_request_set $authentik_uid $upstream_http_x_authentik_uid; proxy_set_header X-authentik-username $authentik_username; proxy_set_header X-authentik-groups $authentik_groups; proxy_set_header X-authentik-email $authentik_email; proxy_set_header X-authentik-name $authentik_name; proxy_set_header X-authentik-uid $authentik_uid; 在配置文件底部添加,请注意的是,需要修改服务地址: location /outpost.goauthentik.io { # 修改 AuthenTik 地址 proxy_pass http://authentik.company:9000/outpost.goauthentik.io; proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie $upstream_http_set_cookie; proxy_pass_request_body off; proxy_set_header Content-Length ""; } location @goauthentik_proxy_signin { internal; add_header Set-Cookie $auth_cookie; return 302 /outpost.goauthentik.io/start?rd=$request_uri; } 此时访问需要验证的服务,跳转到了 AuthenTik 页面。 后语 AuthenTik 在正常使用的时候,坑还是比较多的,整个过程折腾了接近半个月,才完全达到效果。 在部署这个服务时,陆续碰到了以下问题: 访问发生 500 错误 给 API 放行的路径性能太差 放行正则非常难写 详细要说一下,关于配置完成后访问服务发生 500 错误的问题。首先检查一下是否为该应用添加到前哨之中,尝试将 Nginx 配置文件中的外部的 AuthenTik 服务域名更换为内网IP。 如果使用内网IP一切正常,使用公网域名访问不正常,恭喜你咱们碰到了一样的问题。后续我会水一篇新的文章以解决这个问题。 另外我部署了一个 AList用于通过 WebDAV 协议去同步文件,但经过实测,性能差距能有10倍…..这让我放弃了使用 AuthenTik 中放行路径的服务。 这个也会后续水一篇新的文章以解决这个问题。 这里只是写了个大概的使用情况,其他的更多设置,推荐一下 ECWU 大佬关于 AuthenTik 的系列教程,对我有很大的帮助 参考 AuthenTik 官方文档 ECWU AuthenTik 系列教程

2024/9/25
articleCard.readMore

DaRM - 基于 Go 的静态博客生成器

这个项目是我的毕业论文,经常看我博客的朋友会发现,我的站点已经脱离了 WordPress,换成了 DaRM。上个月缝缝补补,将它开源了出来,并且将自己的博客系统切换到了这个程序,目前体验良好。虽说功能是很简陋,但主要还是贴合我的需求,有兴趣的朋友可以玩玩。 DaRM 项目地址:DaRM 基于 Go 语言轻量、快速、易使用的开源博客系统。 文档地址:DaRM Docs 特性 专注于文字 DaRM 系统专注于提供文本内容的创建和管理,尤其适合博客文章和文档的撰写与发布。 原生支持 Markdown 格式,允许用户以简洁的语法快速撰写格式化文本。 易于使用 部署简单,支持不同平台的多种部署方式。 提供了一个用户友好的界面和直观的操作流程,使得即使是初学者也能轻松上手。 性能优秀 基于 Go 语言开发,快速且性能优秀! 静态文件同步 支持将静态文件同步至 GitHub,或通过 FTP 协议同步至服务器。 部署 DaRM 目前支持三种部署方式,编译部署、手动部署、Docker 部署。 编译部署 环境要求 git Go 版本 >=1.22.0 克隆仓库 git clone https://github.com/bitaur/darm.git 构建程序 go build ./ 手动部署 下载 DaRM 打开 DaRM Release 下载对应的平台以及系统的文件。 如果最新的包没有您对应的二进制文件,可以提交 issues ,或可以选择自己编译安装,详见:编译安装。 其中: armv6 对应 arm 架构32位版本,arm64 对应 arm 架构64位版本。 x86 对应 x86 平台32位版本,x86_64 对应 x86 平台64位版本。 手动运行 Linux / MacOS # 解压下载后的文件,请求改为您下载的文件名 tar -zxvf filename.tar.gz # 授予执行权限 chmod +x DaRM ./DaRM Windows 双击运行即可。 持久化运行 Linux 使用编辑器编辑 /usr/lib/systemd/system/darm.service 添加如下内容: [Unit] Description=darm After=network.target [Service] Type=simple WorkingDirectory=darm_path ExecStart=darm_path/darm Restart=on-failure [Install] WantedBy=multi-user.target 保存后,使用 systemctl deamon-reload 重载配置。具体使用命令如下: 启动: systemctl start darm 关闭: systemctl stop darm 配置开机自启: systemctl enable darm 取消开机自启: systemctl disable darm 状态: systemctl status darm 重启: systemctl restart darm 更新版本 如果有新版本更新,下载新版本,将旧版本的文件删除即可。 Docker 部署 首先请确保您正确的安装并配置了 Docker 以及 Docker Compose Docker CLI docker run -d --restart=unless-stopped -v /data/darm:/data -p 9740:9740 --name="DaRM" bitaur/darm:latest Docker Compose 在空目录中创建 docker-compose.yaml 文件,将下列内容保存。 services: DaRM: image: bitaur/darm:latest container_name: DaRM volumes: - /data/darm:/data restart: unless-stopped ports: - 9740:9740 保存后,使用 docker compose up -d 创建并启动容器。 Docker 容器更新 CLI #查看容器ID docker ps -a #停止容器 docker stop ID #删除容器 docker rm ID #获取新镜像 docker pull bitaur/darm:latest # 输入安装命令 docker run -d --restart=unless-stopped -v /data/darm:/data -p 9740:9740 --name="DaRM" bitaur/darm:latest Docker Compose #获取新镜像 docker pull bitaur/darm:latest #创建并启动容器 docker compose up -d 访问 此时打开 localhost:9740 即可打开站点。默认账号密码均为 admin。 后语 最后其实也想说一下,个人水平很差,只是勉强能跑,这个项目的主要需求还是能够让我顺利毕业。很多Bug 还是来不及去修。如果后期有啥问题可以直接留言。

2024/9/13
articleCard.readMore

Docker 部署 Umami,切换数据库至 PgSQL

最近看到 Umami 提示更新,想了想自己好像也很久没更新了, 这一更新不要紧,带来了两个问题: 1、服务器所带来的构建问题 我的 Umami 服务部署于阿里云的轻量服务器。阿里云的轻量,官方说是无性能限制,但在我构建 Umami 时,服务器整体“死机”了两次。而且每次编译的时间较长,所以需要使用 Docker 部署 Umami。 2、官方数据库版本升级带来的问题 由于 Umami 官方自 V2.3.0 版本,开始逐步弃用 MySQL5.7,也由此带来了我之前提到的那个问题:《Umami 构建 2.3.0 版本时 “✗ Command failed: prisma migrate deploy Error: P3009”》。但 MySQL 8.0最少需要4G内存,我的服务器只有 2C2G,所以需要将数据从 MySQL 转移 PgSQL,起初自己折腾到了半夜也没解决数据库迁移的问题,但在 Shell 的帮助下,完成了此次数据迁移,再次表示感谢!! Docker 部署 Umami 如果你需要抛弃数据重新使用或没使用过 Umami ,可以查看此节。但如果你像我一样需要将数据从 MySQL 转移至 PgSQL,可以查看下一节。 将下列配置保存为 docker-compose.yaml 文件。 请注意删除注释以及修改相关配置。 version: '3' services: umami: image: ghcr.io/umami-software/umami:postgresql-latest //如果你在使用国内服务器部署 Umami,可以使用南京大的ghcr镜像:ghcr.nju.edu.cn //image: ghcr.nju.edu.cn/umami-software/umami:postgresql-latest ports: - "3000:3000" environment: DATABASE_URL: postgresql://umami:umami@db:5432/umami //Umami数据库设置,可修改,但也请修改 PgSQL 镜像中的配置信息 DATABASE_TYPE: postgresql APP_SECRET: replace-me-with-a-random-string depends_on: db: condition: service_healthy restart: always healthcheck: test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"] interval: 5s timeout: 5s retries: 5 db: image: postgres:15-alpine environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: umami // PgSQL 数据信息 volumes: - /www/wwwroot/umami:/var/lib/postgresql/data //PgSQL数据库镜像数据存储的路径,请酌情修改 restart: always healthcheck: test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"] interval: 5s timeout: 5s retries: 5 用 cd 命令打开 docker-compose.yaml 的目录,运行下列命令: docker-compose up -d 构建容器完成后,打开 http://ip:3000 即可进行使用。 ​ 默认账号:admin ​ 默认密码:umami 使用 nginx 进行反代操作此处不再赘述。 数据迁移至 PgSQL 需要注意几点: ​ 1、在数据迁移前,需要使用与自编译版本相同的 Umami Docker 镜像,当数据迁移完成后,运行访问服务测试没有问题,再进行升级操作。此处使用的是 v2.9.0。 ​ 2、需要开放 服务器的 3306 以及 5432 端口。 ​ 3、数据迁移后可能会出现一些 BUG,不过我暂时没有碰到(免责声明)。 部署与自编译版本相同的 Umami 将下列配置保存为 docker-compose.yaml 文件,数据库信息的修改请看上一节文件中的注释。 请注意删除注释以及修改相关配置。 version: '3' services: umami: image: ghcr.io/umami-software/umami:postgresql-v2.9.0 //如果你在使用国内服务器部署 Umami,可以使用南京大的ghcr镜像:ghcr.nju.edu.cn //修改为对应的 Umami 版本 //image: ghcr.nju.edu.cn/umami-software/umami:postgresql-latest ports: - "3000:3000" environment: DATABASE_URL: postgresql://umami:umami@db:5432/umami DATABASE_TYPE: postgresql APP_SECRET: replace-me-with-a-random-string depends_on: db: condition: service_healthy restart: always healthcheck: test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"] interval: 5s timeout: 5s retries: 5 db: image: postgres:15-alpine ports: - "5432:5432" environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: umami volumes: - /www/wwwroot/umami/PgSQL:/var/lib/postgresql/data //PgSQL数据库镜像数据存储的路径,请酌情修改 restart: always healthcheck: test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"] interval: 5s timeout: 5s retries: 5 用 cd 命令打开 docker-compose.yaml 的目录,运行下列命令: docker-compose up -d 构建容器启动后,可以进行下一步。 使用 Navicat Premium 迁移数据 再此再次感谢 Shell !!!!! 容器启动后,打开 Navicat Premium ,新建 MySQL 与 PgSQL 数据库的链接。 点击导航栏中:工具 —> 数据传输,左侧 MySQL,右侧 PgSQL,具体配置如图: 点击下方导航栏的选项,具体配置如图: 点击下一步,此处需要传输的表仅四个:session、user、website、website_event 点击下一步,然后开始,此步骤根据服务器配置以及带宽和数据量的不同,所需时间不同。 最后一行显示 Finished with error 则为数据迁移完成。 重启 Umami 以及 PgSQL 容器: docker restart umami-db-1 docker restart umami-umami-1 //具体容器名称可以使用 docker ps 命令查看 访问 http://ip:3000 使用原用户名、密码登录,测试数据是否正确,以及是否有什么 BUG。 在此需要注意:请删除原有的 admin 账户。 如无问题,可进行下一步。 升级 Umami 编辑 docker-compose.yaml 替换为以下内容: version: '3' services: umami: image: ghcr.io/umami-software/umami:postgresql-latest //如果你在使用国内服务器部署 Umami,可以使用南京大的ghcr镜像:ghcr.nju.edu.cn //image: ghcr.nju.edu.cn/umami-software/umami:postgresql-latest ports: - "3000:3000" environment: DATABASE_URL: postgresql://umami:umami@db:5432/umami //Umami数据库设置,可修改,但也请修改 PgSQL 镜像中的配置信息 DATABASE_TYPE: postgresql APP_SECRET: replace-me-with-a-random-string depends_on: db: condition: service_healthy restart: always healthcheck: test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"] interval: 5s timeout: 5s retries: 5 db: image: postgres:15-alpine environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: umami // PgSQL 数据信息 volumes: - /www/wwwroot/umami:/var/lib/postgresql/data //PgSQL数据库镜像数据存储的路径,请酌情修改 restart: always healthcheck: test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"] interval: 5s timeout: 5s retries: 5 运行下列命令: docker-compose up -d 此时,因为需要升级程序数据库,所以根据服务器性能不同所需时间不同。 升级数据库完成后,打开 http://ip:3000 即可进行使用。 使用 nginx 进行反代操作此处不再赘述。 再次强调:请删除原有的 admin 账户。 至此 Umami 数据迁移基本完成~

2024/5/4
articleCard.readMore

癸卯年度总结

时光荏苒,岁月穿梭,又是一年过去了,在这里祝各位新年快乐。 之前没写过年度总结,今年元旦之前,原本是打算写一下的。但是由于那段时间实在是太忙,根本抽不开身,一拖拖到了春节之前,得了,虽然公历新年赶不上了,农历新年之前写完还是没什么问题的。 这篇文章还是我在吃完年夜饭之后才开始动笔写的………………. 生活 说实话,去年(癸卯年)的生活没什么特殊,一如既往的上课学习、水群、做点奇奇怪怪的事情。 但是我和别人也有些不一样,我不爱打游戏,有空愿意刷刷资讯,看看知识类的视频。产生的很多思考,对于意识形态,有了不一样的认识,已经计划写一篇博客聊聊我自己在脑海中构建的意识形态,人的所作所为概括为两个字 “效用”,敬请期待~ 去年年初的定下的目标,看了看,几乎一个完成的都没有。但是我却看的很开,人生原本就是定下目标、制定好详细计划的之后并且放弃的过程。 感觉自己的拖延症已经到了病入膏肓的程度,就比如这篇文章,头半个月已经规划好了,硬生生的拖到了吃完年夜饭,拖无可拖的时候才开始写。。。。 学业已经等于毕业,11月份的时候就回了家,在家已经待了满打满算已经三个月了,也开始了自己枯燥无味的考研学习生活,每天两点一线,早九晚五。 过了三个月才发现每天这样坚持学习真是枯燥无味。。。。这才短短的三个月,我就产生了好几次放弃的念头,曾经有一次深夜自己把自己给逼得破防了,我开始怀疑自己选择的道路是否正确。 但无论怎么说,现在就业环境比较差,考研算是目前比较好的选择,所花费的隐性成本较低,因为就算自己去找工作,也进不了大厂,每月拿着几千块钱工资,累死累活,月月月光,这样属实是没什么意思,还不如视为一个机会,继续深造,为未来做更足的准备。 博客 数了数,去年一共发布了12篇“文章”,真正能称得上文章两个字的,个人认为只有六篇。 根据自建的 Umami 上统计的数据,今年一共收获了 65K 的浏览量,33K 的访客,跳出率有所降低,平均访问时间有所增长。 去年受访问的最多的文章是一篇设置 onlyoffice jwt key 的文章,这文章已经有两三年了,很多操作估计已经失效,但浏览量还是很多,是我万万没想到的。。。。 访问量第二的是 centos7 升级 glibc 的文章,这几天不知道为什么,访问这篇文章的人特别多。。。 寄大希望的文章,浏览量寥寥无几,但是随便写的文章却撑住了我博客的流量。。。 去年来源最多的网站是 百度,其次 谷歌 和 bing,但是百度的权重掉了,今年百度来源的流量会拉。好的方面是现在百度流量的占比不大,对我的影响较小。 今年 去年一年,无论博客的更新,还有学习、生活都是平平无奇的一年。 虽然心有不甘,但是这一年还是过去了,还是展望下未来,定下个目标,到明年的除夕夜回顾起来看看完成了多少。 甲辰年就三个目标:月更博客,学习、减肥。 学习就自不必多说,减肥真是我痛,11月回家的时候才只有150斤,现在已经在通往了190的路上,等天气再暖和一点,买台自行车,每天自习室的路上骑行 10公里,看看能不能瘦的下来。希望到年底,体重能稳定在 140 左右,不要再像今年一样和朋友见面的第一句话就是被调侃又胖了。 那就这样,让我们乙巳年再见。

2024/2/11
articleCard.readMore

小米14 体验报告

手机到手也有半个多月了,因为最近非常忙,所以一拖再拖,这样正好可以更好的体验一下这部手机。 我会从 硬件和软件两个大的方面,分别就优点和缺点去着手进行主观评测。并且对于一些产生的争议问题谈谈我的看法。关于 小米14 的具体的参数,这里就不再过多的赘述。 先说结论:硬件符合价格定位,软件小毛病不断。 序言 先介绍一下我的情况:前 小米10S 机主,对于这台 10S 我只能说爱恨交加,整机质感、还有硬件堆料是比较不错的,但根据我的实际体验,感知更为明显的软件部分,简直可以用一塌糊涂来形容,整个产品的生命周期,负优化不断,不知道是因为小米的软件实力不行,还是故意为之。 真正让我产生换机想法的还是 10S 上的那颗 870 的外挂 5G 基带所带来的续航问题。因为所在的地的 4G 等于残废,所以需要常年打开 5G 功能使用。正常 WIFI 情况下,最高亮度续航能有接近 7 个小时,然而在 5G 的情况下,续航接近腰斩,成为了压死骆驼的最后一根稻草。 恰巧 小米14 正好要发布,其搭载了 Xiaomi HyperOS,以及 8Gen3 处理器,这都是我比较关注的点,所以冲了一波首发,入手了小米14。我手里这台是 16+512 版本的白色版本,所有主观体验均建立于此,不同版本会带来体验上的差异,请谨慎参考。 并且,本片文章并不会针对各种使用场景进行大篇幅的数据分析,如有想了解,可以去观看 极客湾 以及 大米 的评测视频。由于文章是纯主观体验,不同的问题在不同人的眼中可能各有优略,请理性看待,谢谢! 如果这篇文章有您想看没有看到的部分,您可以留言,我会适时添加。 请注意,无论我文章中所说的无论优点或缺点,所有的观点均是我相较于 小米10S 进行的主观评测。可能无法对您起到任何参考意义。如果您是其余品牌其他型号手机的机主,可能某些方面我的主观判断并非完全准确。 此文章对您购机决策产生不了任何的根本性的决策建议。请您去线下的实体店体验,根据自身体验的实际情况再进行购机决策! 硬件 硬件详情 详情可以查看下列表格,更多可以查看 小米官网 部件 参数 SOC 骁龙 8Gen3 屏幕特性 华星 C8 材料 LTPO 120Hz 自适应刷新率 240Hz 触控采样率 DCI-P3 色域 12Bit 色深 类DC调光 尺寸 152.8 x 71.5 x 8.20mm 重量 193g 屏幕PPI PPI:460 等效 PPI:375 电池容量 4610mAh 充电规格 有线:90W 无线:50W 10W 无线反向充电 支持充电协议 Q4C / QC3+ / QC3.0 / QC2.0 / PD3.0 / PD 2.0 / MI FC 2.0 前置 豪威OV32B 1⁄3.14英寸 0.7微米 3200万像素 4K@60hz 后置 主摄:定制豪威OV50H 1⁄1.3英寸 1.2微米 5000万像素 (默认4合11250万像素) 23mm f/1.6全像素全对焦+激光对焦 光学防抖 7P镜头 超广角::三星S5KJN1 1⁄2.76英寸 0.64微米 5000万像素 14mm 115°超广角 f/2.26P镜头 长焦:三星S5KJN1 1⁄2.76英寸 0.64微米 5000万像素 75mm f/2.0 3.2倍光学变焦 10cm以上自动对焦 光学防抖 6P镜头 指纹 短焦屏幕指纹 马达 瑞声 0809B 扬声器 1014 + 1115K 闪存类型 LPDDR5X 4200Mhz 4x16bit,UFS 4.0 外观 优点 先上来让我夸夸小米。 精致 因为我这台机器是白色版本,其铝合金中框进行了亮面处理,这台手机给我带来的第一观感就是精致,而且质感拉满,精致的以至于让我怀疑这到底是不是一部小米手机。我也摸过室友的 小米13 但是 13 的精致感并未有 14 给我带来的冲击那么强烈。 这是一种无法用言语来形容的一种高级感,当然也并非是上一部手机 10S 可以比拟的,终于让我知道了什么是真正的高端机(呜呜呜,上一次给我这种感觉的还是 iPhone) 点亮屏幕,视觉上的四等宽边框,真的让人很难看出差别,如果不是因为没有大刘海还有居中大药丸,这真的让我感觉到这是一部 iPhone,而不是小米。高亮的铝合金中框在灯下反射出的光亮闪瞎我的眼,白色的后盖不易显现出沾染上在其上的指纹,这也是我选择白色版本的原因。 但我愿意把这种质感归结于机身重量的加持,小尺寸,大重量。让人有一种的扎实的感觉,再加上亮面铝合金的加持,以至于让我产生了高级感还有精致的一种感觉。 当然,用言语是无法讲出这种感觉的,建议有兴趣的小伙伴可以去线下去摸摸,如果你看完这篇文章还有兴趣的话。 机身三围合理 让我选择这台机器最大的原因,估计还是因为它是现在市场上为数不多的 “小屏” 旗舰。在 71.5mm 的宽度加持下,可以让我单手完成很多操作,不再像 10S 一样,让我很多操作必须使用双手去完成,这给我带来了极大的便利,以及非凡的握持体验。 很多人认为小屏等于屏幕小,以至于当我说这是一台小屏机的时候,有人说:“这台手机屏幕已经 6.36英寸 了,还怎么能算的上小屏手机。” 其实不然,以往受限于技术限制,手机屏占比无法做到现在这么大,所以以前的小尺寸机器都把屏幕做的很小,当年差不多长宽的 小米6 才 5.15英寸,所以以往定义的小屏其实只是相对小的机身尺寸而已,无关屏幕的大小,更多与之挂钩的是手机宽度。 现在还在坚持做小屏机器的厂家已经很少了,到发文止,在做小屏旗舰的只有 三星、苹果、还有小米。三星S数字 与苹果 Pro 的同版本售价让我望而却步,一部的售价可以支持我买两台小米旗舰………而苹果数字款…….实话实说,我无法接受在 2023年 快到 2024年 的时间点上在这个价位段,再去购买一部仅有 60Hz 屏幕的手机。 Fuck Cook!!!!!! 顶部设计 这次 14 的顶部变成了无开孔的设计,将红外,扬声器以及麦克风通过设计移到了摄像头模组还有其他地方上面,虽然观感上会变得让机器变得更加精致,但在使用中也会带来一些问题: 红外移到了摄像头模组上,会让实际使用这项功能的人变得十分不爽,需要将手机垂直对着设备,才能进行正常使用红外,无疑带来是巨大的使用成本。 本身扬声器就不是对称双扬,这样改变了音波的传递方向,在实际体验中,顶部的扬声器声音会偏小,底部偏大,这部分感受比较明显,但音色差距比较小。 关于麦克风,这部分的影响应该是最小的,在实际的体验上,没有明显感知到与之前机型的收音效果有何明显差距。 由于本人使用红外的场景极少,扬声器还有麦克风的使用影响较小,所以综合来看我还是给这种顶部无开孔的设计方案算一个优点。 前面板 2.5D 玻璃 这样做的好处非常明显,可以保证在进行手势的交互(特别是左右的手势交互)时可以让手感相对来说更加顺滑。当然这么做不是没有缺点的,会非常挑钢化膜,很多钢化膜都会出现白边的情况,当然你了可以跟我一样,买个MiCare(强烈推荐),做个裸奔党。 视觉四边等宽 这也算是一个不错的优点,如果还是大黑下巴还有上巴,真的对外观来说很拉分(此处点名某 100)。 甚至个人觉得就算三边继续收窄,下巴宽度不变,都十分影响观感。虽然较 13 差了 0.1mm,实际来说应该是观察不到的,但在看 13 的时候让人产生一种心理暗示,让你觉得 14 的下巴肉眼可见的比 13 窄,小米属实把心理学给研究明白了。但于此同时,你还会知道下巴比其他三边宽 0.1mm 也很难让你实现视觉上的 “四边等宽”。 缺点 说完了优点,再让我来说说更多的缺点。 机身外部按键松垮 上手之后,在我使用实体按键时,就感受到了按键的松垮,按键下去并不清脆,除传统的按压操作外,这个按键还可以水平的上下左右的调节,这直接让我震惊,刚上手就翻车。 在以为自己中奖了之后,后来在微博看到首发用户的评语,发现这并非个例。甚至有人说这是小米的祖传问题,在不同机型上都有此问题,拿来了室友的 13,果然发现了同款的问题,这真的非常影响体验,也影响我对这台机器的印象。当看到是大范围的问题,让我放弃了换机的想法,又不是不能用。 后来看到有人说为了防止卡键,由于不了解其中机理,所以不好妄下判断。但有人的松动,有人不松动,这就证明可能是品控的问题,一台这个价位的机器还做不好细节把控,差评!!!! 背部盖板与中框并不顺滑 这部机器虽然在背部玻璃盖板做了弧面处理,但与中框过度并不顺滑,大概如下图: 而且你是能明显看到中框是突出一部分的,加上中框没有做弧度处理,在握持的上会感到硌手。这算是一种非常取巧的方案,可能旨在降低手机厚度对手感的影响,这种方式常见于曲面屏手机,但直边手机使用这种设计,个人感觉弊大于利,因为解决一个手感问题,又带了更严重的问题,典型的偷鸡不成蚀把米。 重量较重 整机重量达到了 193g,这是一个很高的重量,就算是我裸奔持机,在单手使用的时候都能感觉到小拇指隐隐作痛…….但谁让这台机器内部堆料太狠,这个重量也可以接受,我忍了…….. 希望在下一部机器上小米可以重视这方面的问题,在整机用料机身强度不减的情况下,可以尝试一下使用更轻便的中框材料,来减轻整机重量。 中框容易粘指纹 金属银色亮面中框虽然质感拉满,但其更容易显现指纹以及划痕,介意的朋友可以注意这一点,选择其他颜色版本。 银色亮面基本上都有这种问题,这就仁者见仁智者见智了。 巨大的摄像头模组 这是我认为外观上数一数二的缺点,这么大的摄像模组,导致后背看起来不如 13 的摄像头模组来的协调,同时取消了 13 上广受好评的分割线设计,取而代之的是中间的大 “LEICA” 以及上方的圆形闪光灯。 在观看楼斌的拆机视频可以看到,以小米之前在机型上展示的内部堆叠示例来看,整个摄像头模组其实是可以做的更小的。 为什么没有呢,这是就是典型的为了设计而设计,强行与13做出区分,把整个模组设计的过于巨大,以至于整个背面非常不协调。 相机硬件 前置 这次前置摄像头使用的是 豪威 OV32B,具体参数可以看前面的表格,相较于 10S 上的那颗三星 S5K3T2 无论是硬件规模还有前置算法方面都可以说是一次跨越式的进步。 虽然作为一个肥宅,十分邋遢,但也不妨碍本宅有爱美之心,有时也忍不住拿起手机打开抖音带的美颜相机,小拍两张。10S 的前置哪怕是拥有抖音这么强大的算法加持下也都拍的惨不忍睹,感觉有层白雾糊在照片上。 由于软件算法层面带来的提升,整体的成像质量非常不错,整个画面的纯净度有了质的变化,特别是默认相机的前置成像,以及各类需要前置的摄像的APP表现中,无论是画面纯净度还是整体效果都有较大的提升。虽然整体提升较大,但呈现的效果还是远不如苹果。 因为隐私问题也无法放出具体的人像照片,敬请见谅。 后置 主摄使用了 OV50H 类似物,官方命名为 光影猎人900(定制版OV50H),与 OV50H 最主要的区别在于算法上的定制优化,固定F/1.6光圈,1/1.3 英寸大底。全像素全向对联,支持光学防抖,7P镜头,需要注意的是8K录制仅支持24帧且最高录制仅支持6分钟。 长焦使用了三星JN1,1/2.71 英寸 F/2.0 支持OIS光学防抖,10cm以上自动对焦,6P镜头。需要注意,3.2倍长焦 是基于2.6倍变焦裁切下来的。 超广角使用的也是三星JN1,支持115°超广角,6P镜头。 这一套影像系统相较于 13 来说升级幅度较大,也是这次主打的升级卖点,更是比10S高到不知道哪里去了,你要问我好不好,当然是好哇!!!! 骁龙8Gen3 CPU 这次的骁龙8Gen3使用的台积电N4P工艺,从各大UP实测的能效表现上来看,相较于 8Gen2 上的 4nm工艺,提升幅度也算不小。一个3.3Ghz的X4超大核,缓存容量从1MB提升到了2MB,三个3.15Ghz A720,两个2.96GHz A720,外加两个A520。三级缓存也从8MB提升到了12MB。 从极客湾的测试表现来看,这两个A520纯纯是累赘,还不如接着再砍掉一个,仅保留一个以维持整机的待机功耗。 由于ARM作死般的政策缩紧,这一代骁龙8系列旗舰处理器,也是最后一款使用ARM公版架构的处理器,根据目前看到 X Elite的表现来看,我对明年高通的新自研架构还是挺有信心的,不过就算翻车也没事,反正我也不换。 这里放个极客湾的8Gen3 CPU 能效曲线作为参考。 这里为了便于对比,仅罗列了8Gen3,8Gen2以及骁龙865的CPU综合能效曲线。从图中可以看到,无论是低负载还是高负载,8Gen3的整体能效表现相较于8Gen2都有着不错的提升幅度。在6W的功耗情况下骁龙8Gen3,相较于8Gen2,综合性能提升13%-16%,相较于865,拥有着临近50%的性能提升,在峰值性能上多核提升甚至能到30%。 顺便说一下为什么峰值性能会如此重要。 在日常使用中,当你打开一个冷应用(即很久未打开使用的应用)这是最考验的便是峰值性能,应用在启动时会在极短的时间内,请求大量的运算资源。这不仅考验的是厂商的条件能力,更是考验SOC峰值性能的时候,如SOC峰值性能不高,或剩余可用的计算资源过少,就会导致应用的卡顿。 为什么要选择6W作为对比的点。 手机是无法时刻跑满SOC的,因为受限于硬件条件,很多手机在性能持续输出时仅能持续输出6w(部分手机仅支持4W)的SOC发热,所以更高的功耗已经不具备了参考的意义。 GPU 这次高通并未更换架构,只是简单粗暴的提升了GPU规模,且拉高了频率。 具体能效表现还是请看下图: 从图中来看,750相较于740在能能效上并无太大的提升,更多的是在于峰值性能的提升,当然与此同时,带来了更为恐怖的功耗提升。由于不太玩游戏,所以此处不再过多点评此GPU,但根据多家评测来看,这次 8Gen3已经可以征服 720P 全高元神了。 865:喵喵喵? 屏幕 屏幕观感 虽然小米吹的这块屏幕怎么怎么好,据我实际的体验来看,这块屏幕在很多场景下不怎么让人讨喜,各种颜色均有发灰的情况,不过好在这块屏幕给了非常丰富的色彩管理,但无论怎么调,整体色彩感觉还是不如10S上的那块华星光电默认的色彩。 由于1.5K的分辨率以及屏幕缩小的加持下,在屏幕精细度方面表现不错,虽然与LCD无法比拟,但通过算法的加持,也是十分接近。 但1.5K分辨率也带来了一些问题,在一些游戏或应用中,整体画面精细度甚至不如1080P屏幕更大的10S,这一点需要特别注意。 整体观感感觉可以用一句话总结:黑色很黑,白色偏灰。 频闪 原本不想讲频闪的,因为大佬强烈要求,所以加上了这点。 小米14的频闪方案是比较常见的,高亮度下是 120Hz TFT 类DC调光,过了切换点(大概是亮度条的30%左右)就会切换到 480Hz 低频 PWM 调光。 系统内部提供了开启全程类DC调光的选项,默认是关闭的,打开后对于屏幕的整体色彩,以及低亮度下的屏幕可见程度产生一定的影响。主要体现在于屏幕灰度色深会产生不同程度的偏移,以及影响显示精度的情况。 关于占空比之类的信息,由于没有专业设备,我也无法进行数据测量以及分析,大家可以参考洋芋的这个视频 LTPO 这也算是这块屏幕的一大卖点,相较于无 LTPO 的机器, LTPO 可以做到对于屏幕刷新率的动态调节,以降低屏幕功耗。 以前在使用10S的时候,因为屏幕整体仅有 90Hz 刷新率,如果强制高刷对于整机续航影响较大。后来也尝试了各种各样的方式实现了三档的可变刷新率,当时的测试结果是在不影响正常使用的情况下(保证应用内全程高刷,在观看视频或屏幕不在操作时降低刷新率),还可以保证增加了一个小时的亮屏续航时间。 但是LTPO也是有它的问题的,由于这是一种硬件特性,你无法将其彻底关闭,哪怕你强制锁定了 120Hz 它也会生效。主要会对屏幕色深产生一定的不利的影响。 续航 14的续航总体来说让我非常满意。 我可以说一下我当天的续航使用情况:全程最高亮度,5G单卡网络,LTPO,打开深色模式,无游戏,绝大多数情况是B站视频以及短视频还有信息流。 100%到20%电量,最终使用时间8小时7分钟,根据屏幕时间管理显示,亮屏时间5小时31分钟。 我感觉自己已经属于极度重度使用了,如果是中轻度使用,续航撑起一天问题绝对不大。 快充(怒喷) 一说到快充,我就有的喷了。 小米14支持90W有线,50W无线,10W反向充电。有线充电18%到前台显示100%大概是40分钟整体不算慢(未开启快充加速)。 好了我要开喷了,喷的点是什么呢就是下图的这个东西——快充加速。 原本来说这个功能是挺好的,可以让你的手机充电更快,但打开这个功能就会有一个非常恶心人的情况发生——手机续航大幅减少。据我实测打开这个功能,确实可以让你前台显示充电到100更快,但是冲的快掉的也快,充电时间可以节省接近一半,同样的续航也掉了能有一半。 众所周知,快充和大电池不能兼得,小米是如何实现大电池和百W级快充的呢(以下情况仅为猜测): 估计就是限制电池使用的容量,限制电池的部分使用容量,进行UI快充,前台显示100%但实际快充的电量仅有60%左右。让你产生这台手机快充快的假象。 我和不同人都确认过这个情况,当开启快速充电这个功能后,续航就会变得很差,并非个例,在小米不同机型不同高功率快充的机器上均有此现象发生,让我更加确信自己的推断是正确的。 扬声器 顶部扬声器与底部扬声器分别是 1014规格与1115K规格,因为是非对称双扬,且声音传递的方向都不一致,再加上规格较小,所以就不要对14的扬声器抱有太大的期望,带来的只是失望。 唯一让我庆幸的是,虽然你能明显感受到上下扬声器的音量有些许差异,但两个扬声器的音质表现竟并未感受到多少差异。 我再也未见过能和 小米10S 双扬相媲美的手机,一台都没有,小米10S 赛高!!!!!!! 手感 上面在外观部分说了,小米由于的取巧的直边设计让整个手机握持手感并不佳,会感觉到非常硌手。再加上整个机身重量的加持下,长时间的使用,直角边框会让你的小拇指时常被硌出一条痕,这点就非常难受。 巨大的摄像头模组会让你时常摸到它,特别是官方吹了很久的巴黎饰钉的设计,我觉得当个指甲锉不错。 做的比较好的是没有太大的头重脚轻的感觉,剩下的就是直角边框的通病,需要较长时间的适应。唯一让我欣慰的就是整机是一台宽度仅有71.5mm的小屏机,这也是我选择14不选择再等等的一个很重要的原因。 其他优点 湿手触控 作为低人一等吹了那么久的功能,小米这次也上了,所以打算作为一个优点来讲讲。 据我实际体验在手上沾水的时候触摸准确度相较于10S确实有质的提升。 以往在洗衣服,还是刷碗的时候来了电话,手上有水一整个不好就把电话挂断了,甚至有时候因为残留在屏幕上的小水珠,还会让我观察到手机在“发疯”。但14上因为有了这项功能,几乎没有再出现这种问题。 IP68 有总比没有好,这个部分这里就没有办法测试了,毕竟防水不防傻。 手机的IP68会根据手机的使用情况不同,例如磕碰,较大幅度的放置手机,都会让手机一步步的丧失掉气密性,有时可能短短一周就会让手机失去这种等级的防护能力,所以请勿用水洗手机。 请注意,小米的线下售后是没有能力恢复手机的气密性的,在线下拆机就等于手机失去了 IP68。 USB3 5Gbps 虽然不是 10Gbps,但总比 USB2 好。换算下来,还是能有 600MB/s 的速度,用来备份手机数据,还有传输大文件的时候可以事半功倍。用不到的人永远不知道它的好,只有当你需要它的时候才知道它能有多重要。 其他缺点 短焦指纹 这可以说是这台手机硬件配置上的为数不多的巨大遗憾,都已经2023年底了,4000+价位的手机还在使用短焦指纹。 虽然说解锁精密度还有精准度不错,但由于位置太过靠下,会让解锁体验有一定的下滑,对于部分用户来说可能需要很长的时间去适应。 5G频段缺失 这次小米14还是缺少了部分5G频段,例如N7 N79 N20等频段 虽然对在内陆还有部分海外国家使用没有影响,但对使用上述5G缺失频段的国家还是有很大影响的,如果您有在海外上网的需求,可以先查询14是否支持你目的国家的5G频段。 USB3 5Gbps 未配备 USB3 数据线 既然都支持USB3 5Gbps了,送能用的线不过分吧,成本贵不了多少钱,你这送个2.0的线,也就让我充个电用,我望着家里快要泛滥成灾的USB2.0 数据线陷入了沉思………. 关于出厂自带的保护膜 建议到手就撕,十分影响观感,小米省钱都省到这个上面来了,还因此引发了一波负面舆论。 据我使用的那几分钟来看,这玩意手感极差,貌似还没有疏油层。 软件 软件版本介绍 这次 小米14 预装了 Xiaomi HyperOS,但满满充斥着这是 MIUI15 换皮的味道,充斥了各种各样的小 BUG。 以下我提到的优点以及问题 全部基于 Xiaomi HyperOS 最新稳定版本 1.0.24.0。 深色模式(巨烂) 这个深色模式我已经不知道怎么去吐槽它了,所以我把它放到了软件体验部分的开头去批判它。 自从 MIUI 进入了 Android 12 为底层的世代,所有基于 安卓12 以及更高版本的无论 MIUI 还是 HyperOS,这个功能约等于残废。 系统应用 对于系统应用来说,深色模式适配的肯定非常不错,但在天气APP上,为了强行划分出白天黑夜,就算开了了深色模式,一打开天气,整个 APP 的部分模块还是白色,非常影响整个系统的协调性,非常突兀。 第三方应用 这次第三方应用才是重灾区,以往的深色模式,虽然有很多APP没有适配深色模式,但系统可以强制让它们使用深色模式,但自进入 安卓12 世代以后,这项功能等于没了。 最新的系统情况下,在深色模式设置中,仅有仅有少部分应用支持打开这种强制适配深色模式。以往虽然强制适配的深色模式有些小问题,但是整体可以让系统色调更加的协调,更让人易于接受。 我更希望官方能够将这种 替应用适配深色模式的选项给添加回来,否则晚上打开一个 APP 直接亮瞎眼……..我猜绝对不止我一个人…….. 对了,小米商城到现在都不支持深色模式,它到底算是系统应用还是第三方应用? HyperOS 重头戏~ 优点 丝滑,丝滑,还是他妈的丝滑! 流畅,流畅,还是他妈的流畅! 动画 这次 HyperOS 上的动画可以用丝滑来形容,我可以相信这是 MIUI12 上画的饼在 HyperOS 上实现了,无论是应用打开、打断动画还是多应用打开动画,直接上图: 应用打开返回动画: 应用打断动画: 多应用打开打断动画: 从图中可以看出 HyperOS 可以用优雅来形容,第三个图片因为大小问题,所有加速了一下。这种优雅的动画不仅存在于应用打开切换,还存在于系统的各个角落之中~ HyperOS的流畅度这次真的成了! 实时毛玻璃(高级材质) 这次 MiKOL 吹的比较狠的除了流畅度外,就是这个实时毛玻璃了。 这个功能官方叫做:高级材质,你可以在 设置—显示与亮度 里找到选项。但由于这个功能需要不小的性能开销,而且我并没有觉得这玩意高级到那里去(主要是丑),所以并不建议开启,当然如果你觉得这玩意特别高级,比较好看的话可以开启。 系统不少地方都能看到它的身影(由于此版本小米阉割了高级材质,所以展示不多): 应用长按的快捷方式: 控制中心: 还有部分系统应用: 相册: 笔记: 文件管理: 焦点通知 这次新的通知方式非常简洁美观,也是我吹爆的一项新的功能,话不多说,直接上图: 验证码: 录音机: 游戏登录更加文明 这次HyperOS 在游戏登录时,不会再进行前台上得应用切换授权,而是使用了小窗唤起需要授权的应用。这很文明,很有精神! 更多 其实小米此次更新了极多的新特性,由于篇幅在此便不再过多介绍,在此挑出几个我个人比较看重的说一下。 目前有消息声称小米可能还会再办一次发布会以更好更全面的介绍 Xiaomi HyperOS,在此期待一下。 缺点 BUG,BUG,还 TMD 是 BUG! 额头隐藏掉了更多的图标与交互 在这次更新中,小米去掉了默认状态栏中部分图标,比如 VPN 图标、蓝牙耳机点亮等图表,这非常影响交互体验。特别是VPN图标的去除,让我很多时候都意识不到 VPN 到底是开启的还是关闭的,需要下滑呼出控制中心,才能直观看到更多的功能开关信息。 隐私提示从左侧大的图标,改成了右侧的小点,变成了下面这样: 以至于让我很多时候都意识不到这个小绿点的存在……程序在后台干了什么就更不知道了……. 快捷方式去掉了文字说明(勘误,需要手动打开) 如我下图所示:控制中心的快捷按钮去掉了文字,而且部分图标还进行了更新,让我时常按错,打开了不需要的功能,关闭了需要的功能,特别是有些应用不同的功能使用一样的图标,你这让我怎么进行区分? 虽然在编辑图标中有文字,但并不能直观感受到什么按钮是什么功能,而把这种为了设计而设计的UI所带来的巨大学习成本强加给用户,让我真的想骂人! Bug,Bug,不间断的小BUG 自首批到用户到手,已经也将近一个月的时间了,稳定版本从出场版本 06 开始,在一个月间陆陆续续的竟然更新了7个 HyperOS 版本升级,以用于不断修复系统体验上所带来的BUG。这简直让人难以想象。 但就目前而言,小米14 的稳定版,还更加像是开发板,一周一更,甚至一周两更,根本无法做到真正的稳定,到手之后一个月竟然还有如此多的 BUG,还一味的想让用户包容,凭什么?更让人费解的是,在最新的 1.0.24.0 的系统版本中,关于我上述介绍的新系统特性竟然砍掉了一大半。这让我更加怀疑这个HyperOS 是不是赶鸭子上架。 这个价格的机器,已经真的可以说是旗舰了,可在小米社区的 BUG 反馈中,搜索一下小米14,其反馈我滑了很久也望不到头,一款旗舰机为什么会有真么多的BUG?难道前期这么久的研发时间当中没有测试出来?我于 11月15日 反馈了一个BUG,但直到今日我还没有收到任何反馈。 难道这就是小米所谓的高端?如果这真的就是小米口中的高端,天天在高管口中说的高端,那小米的高端永远也成不了,没有那么多用户愿意跟你去折腾,没有那么多用户有义务陪你折腾。诚然性价比看着怎么怎么无敌,但软件服务上就是一坨屎,还是一坨没有拉完的屎。 其他 灵动额头 这次充电动画也产生了变化,在亮屏状态下,充电的动画变成了类似于苹果灵动岛的设计,只能说有点丑,但莫名的还可以接受。 部分系统应用 UI 重构 通话、短信、相册、文件管理、天气、日历、笔记等应用均进行了 UI 交互逻辑上的重新调整。 其中通话、短信、 笔记、文件管理、相册是将上方的工具栏移到了下方。 笔记: 通话: 文件管理: 相册 而变化最大的还是天气APP,进行非常彻底的重新设计,添加的新的天气动画,重绘了部分UI设计 相机拍照 我这里更多展示的是 小米14 夜间的AI自动摄影。 为什么选择AI+夜景。因为很多人并不会所谓手机的的高级功能,顶对会对一下焦,试问有多少人会对照片,什么光圈,焦距,曝光时间,ISO什么的有所了解?绝大多数人不还是拿出手机对准了,对个焦,咔嚓一下就拍完了?使用AI相机更多的是可以看手机相机算法如何。而夜间拍出来的成片是否纯净,更考验的是相机的硬件素质。所以两者相结合,更能体现出一台手机的相机整体素质如何。 当然这并不全面,仅是个人理解。 3.2倍长焦夜景: 前三张图片,无论是灯箱,还是暗部细节表现均不错,且整体照片的质感比较纯净,但暗部细节部分略有缺失,3.2x 长焦照片,上方灯箱也比较清楚,但噪点明显增加,暗部细节丢失严重。我对于14的相机部分整体成像能力还是比较满意的,但具体如何还请你结合样张自己进行评判。 HyperOS 互联交互 由于手中的平板还没有更新 HyperOS,所以后续再进行增加评测。 总结 这台机器给我最大的惊喜,不仅是骁龙的能效提升,而是 HyperOS 带来的流畅度的提升,相较于之前的MIUI版本,这次的 HyperOS 确实带来了相当大的改变,无论是动画,还是系统的整体流畅度稳定性来看,都有了长足的进步,但这并不是算是小米的优势,只能说小米补足了劣势。 小米14可以说是一部硬件上非常有竞争力的机器,虽然很多友商对小米14进行碰瓷式的营销,这恰恰证明了它的强大。而 Xiaomi HyperOS 所主打的人车家智能生态,需要更多的时间去验证,在我眼里它现在仅仅只能算是一个不错的手机系统,仅此而已。 但在能提供的配套服务上,它都不足以支撑起这个售价。就像是我在 HyperOS 缺点部分说的,关于 小米14 的 BUG,一个发布一月的机器,现在手里的手机还是堪堪可用的状态,虽然大毛病没有,但小毛病从来不间断,这不是一个这个价位的旗舰机该有的表现。让我诟病的小米对于旗舰用户问题处理的态度,一个反馈了半个月的问题,到现在一点反应都没有,哪怕是回个消息:了解了。让我知道我提出的问题有了下一步。我也不至于如此的生气。 综合来看,满分100分,我能给它打一个90分成绩,这是一张非常优秀的答卷,为二让我觉得不爽的还是 HyperOS 上那些不断出现的小BUG,以及小米对于BUG反馈的态度。虽然我在这篇文章中喷的有点多,但并不妨碍 小米14 是一台非常优秀的手机,等修复的系统上现有的这些小 BUG,我愿意把它的评分,提升至完美。 资料参考: 小米14官方页面:https://www.mi.com/xiaomi-14/specs Xiaomi HyperOS:https://hyperos.mi.com 极客湾:https://www.bilibili.com/video/BV1me411R7Ha/ 微机分WekiHome:https://www.bilibili.com/video/BV1Wu4y1Y78b/ 大米评测:https://www.bilibili.com/video/BV1XM411f78e/ 洋芋PotatoNE:https://www.bilibili.com/video/BV17g4y1o7xw/

2023/11/27
articleCard.readMore

博客托管 Cloudflare Pages 后,关于 RSS 订阅链接的问题

由于之前 Vercel 的 IP 在国内被跳反炸,而且域名并未进入预加载列表,导致访问我的站点时会被跳反炸。让我意识到可能 Vercel 不再适合我了,让我产生了将博客部署到到 Cloudflare Pages 的想法。 虽然速度上来说 Cloudflare 到境内的线路质量不太理想,但胜在相对来说比较稳定,不会大规模的跳反炸页面。再加上,相信访问我博客的人应该有办法自己加速,以访问某些网站。 前提 迁移了一段时间之后,我发现访问博客的 RSS 订阅链接出现了点问题,访问 roy.wang/feed/ 时会显示首页的内容。 了解之后发现,似乎是因为安全考虑,Cloudflare 是不支持将非 index.html 的页面设置为默认页面的。而 feed 的订阅文件,一般都是 xml 文件,使用插件生成的静态文件也是 index.xml 。导致直接访问 /feed 路径会产生无默认页面的情况,然后返回主页的内容。 并且,Cloudflare Pages 似乎既不支持非 index.html 文件设置为默认主页,也不支持显示页面的.html 结尾。当你访问 /pages.html 时他会自动跳转到 /pages 显示正确的内容,但并不会显示 .html 文件的后缀,如果有知道的大佬可以留言告知一下。 解决问题 而我翻遍了文档,也并未找到官方给出解决方案,以及为何不支持此种操作的原因。但可以通过 Transform Rules 然后进行 URL 重写解决问题。 最开始时,我是想通过规则进行 301 跳转去解决这个问题的,但很多 RSS 订阅器不支持进行跳转操作获取订阅文件,所以放弃了这个想法。 既然显性跳转不行,那就不如隐性跳转。 此方法也存在局限性,即需要域名使用 Cloudflare 的DNS,如使用 CNAME 接入,理论上也是可以的。 在 Cloudflare 面板找到 Transform Rule -> Rewrite URL -> Create Rule 进行创建新的规则。具体规则参考如下: 然后保存即可,主要是设置正确需要进行转换规则的路径,以及转换后跳转的地址。 至此访问 RSS 订阅链接的错误基本解决。

2023/11/18
articleCard.readMore

小白如何正确使用 Windows

这篇文章仅献给没有 Windows 良好使用习惯的小白。 谁是小白?当你的 Windows 系统越用越卡、C 盘占用越用越大、PC开机慢、软件各种弹窗、经常蓝屏死机但重装系统后又正常如初、使用软件各种卡顿。 那么你既是小白。 并无贬低的意思,因为人都是从小白过来的。身边越来越多的朋友无法保持良好的 Windows 使用习惯,进而导致电脑出现上述问题以及其他由于不良习惯而导致的问题。但是在互联网上并未找到合适的适合小白的良好习惯的使用教程。 此篇文章仅是我这么多年来使用 Windows 的个人经验,可能并不全面,如您有更好的建议,请您在评论区指出,谢谢!! 由于限制,本篇文章仅基于 Windows 11,其他电脑系统仅供参考,但思路是一样的。 关于 Windows 系统版本选择 首先,默认是安装正版的 Windows 操作系统,并非是使用了 XX精简版,XX优化版等二次打包的 Windows 系统,这种系统精简掉了各种系统服务进而达到了 “流畅” 的目的,但也可能带来了潜在的风险:系统不稳定、被植入的病毒、自动安装各种各样的软件、被当成肉鸡。 关于 Windows 系统的选择,可以选择 I Tell You 去下载原版的系统镜像。此时需要注意提供的选择中并非是全部可用: 以上图为例,其提供的三个选择中,前两个 Windows 镜像分别为商业版镜像、消费者版镜像。 其中: 商业版中包括了:专业版、企业版、教育版、专业教育版、专业工作站版。 消费者版中包括了:家庭版、专业版、教育版、专业教育版、专业工作站版。 其中不同版本的区别,此处不进行列举,普通用户推荐使用家庭版以及专业版即可满足所有需求,不用担心这两个版本无法满足您的需求,如果您有特殊需求,肯定会知道该如何选择 Windows 版本 此时需要注意 ARM64 的版本,此版本并不适用于普通的 PC 以及笔记本电脑使用,此版本是供使用 ARM 架构 CPU 的笔记本 PC 使用的。 另外,当您选择 Windows 10 即以下系统版本时,可能会有会有 32 版本,当您内存小于 4 GB 才推荐使用 32 版本,否则请您使用 64 位版本。 还有一个特殊的 Windows 版本:Windows LTSC,此版本是为对稳定性、流畅性、简洁性要求较高的用户准备的。当然也要付出一些代价:无应用商店、功能更新缓慢。 注:最新的 Windows LTSC 基于 Windows 10。 关于如何选择 Windows 版本,推荐使用 Windows 11,某些性能较差、或特殊需求才推荐使用 Windows 10 甚至 Windows 7。 关于软件安装卸载的问题 关于软件安装 很多人都是因为并无良好的软件安装以及分类习惯,才导致 C 盘越用越小、系统越用越卡。 还需要明确盘符的用途,一般来说,电脑中默认会有多个分区盘符,C、D、E等。其中 C盘 为系统目录,请不要主动往此盘符内安装一般程序。 但也有一些例外,如无法选择安装目录的软件如 Chrome、Office等。硬件的驱动软件,都是可以安装到C盘之中的。 此处以安装 QQ 为例。 首先是如何下载安装程序 百度通常是国内用户的首选,甚至很多用户浏览器用户被各种导航页面把持。当你在百度搜索 QQ 时会出现很多选项: 此页面包含了 1-4 四个选项,其中 3、4 是关于 QQ 的百度百科以及微博,这些可以忽略。 1、2之中,很多小白都会选择 2 中的 普通下载,甚至所谓的 “安全下载” 去下载软件,这种习惯是非常糟糕的。此时安装的软件可能并非是最新版,甚至是带捆绑安装的软件包。安装一个软件,可能会安装一堆软件。 正确的步骤为点击带 官网 标识的 1 链接,来下载安装程序。 当然很多软件,如下文中提到的 Geek Uninstaller 在百度上是不显示官网标识的, 此时就需要仔细判断其是否为该软件的官方网站了。 打开下载页面,选择下载选项,选择正确版本的安装包进行下载。 关于软件的安装流程的配置 当你打开安装包,不要点击立即安装 使用其默认配置去安装软件,此时安装程序会将你的软件默认安装到C盘,进而导致 C盘 越来越小,系统越用越卡。 点击自定义选项,可以看到很多自定义项,其中最关键的是 安装目录 的配置 个人建议是使用分类管理的方式去配置安装目录: 其目录组成 :如上图所示,直接在D盘使用一级目录,一级目录的名称应该是简洁明了的,一眼可以看出这个文件夹中安装的是什么程序,但请不要使用中文目录!!!!!!! 如果需要安装的程序较多,可以将软件使用一级目录分类,将软件安装到二级目录中,如将 QQ、WeChat、Telegram 之类的软件安装到 Chats 目录下,如Steam、Epic、WeGame之类的软件 安装到 Games 目录下。也可以将一些功能性的目录如下载目录 Download 设置为一级目录。 其目录结构示例如下: 注意:QQ 之中下面还有一个用于保存消息记录的地址,建议也通过上述分类的方法,将其保存在特定的目录中,以便清理。 请不要选择开机自启动。 关于软件安装过程中的额外软件安装选项 如上图所示,软件安装完成后以及安装流程中,会默认勾选很多安装软件或设置主页的选项,请注意甄别。否则连锁反映下,软件会越来越多。 总结 选择官方网站进行下载安装程序,做好软件安装分类,不要安装到 C盘,注意软件安装过程中,是否有额外安装软件或设置首页的选项。 关于软件的卸载 软件的卸载通常是很麻烦的,微软默认自带的软件管理还是不够好用,很多软件无法卸载,而且也无法删除一些注册表以及残留文件。 国外成熟好用的卸载软件很多如付费软件:IObit Unintaller,以及还有免费好用的选择:Geek Uninstaller 此软件是免安装的,打开即用,建议将其放入特定的目录中 如 D:\GeekUninstaller 设置快捷方式,来方便使用。 当你使用该软件卸载软件完成时,它会自动检测是否有文件或注册表残留,以及自动清理。 系统功能的设置 主要还是在于 Windows 系统的自启动问题,很多时候软件安装完成后,默认会开启自启动。一打开计算机,软件即会自动运行,导致可能原本就不多的内存直接被吃满,进而导致系统的卡顿,很多人的电脑越用越卡这也是重要的原因之一。 关闭软件开机自启动 关于设置软件的开机自启动,在 Windows 10 以及 Windows 11 中,微软在任务管理器中内置了开机启动的管理选项。 按下 Ctrl+Alt+Del,即可快速唤醒任务管理器,点击启动应用即可进行管理。 由图可见,诸多开机启动选项,多数均是默认为开机启动的,个人建议,如无特殊需求可全部禁用。 关闭 Windows 系统自动更新(可选) 正常来讲,Windows 的更新在于修复 BUG 以及推送新的功能,但会有小部分情况中,Windows更新会带来更大的 BUG,可以基于您的情况,选择是否关闭 Windows 更新。 Win + R 打开运行输入 cmd 打开,输入以下命令: reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" /v FlightSettingsMaxPauseDays /t reg_dword /d 5000 /f 关于 Windows 的使用 很多时候如不能保持良好的使用习惯,还是会拖慢系统的速度,以及出现各种各样的问题。 不要下载未知来源以及未知的文件 一般来说安装了杀毒软件后,下载了危险的软件和文件基本上杀毒软件会自动检测并且强制删除,但某些情况下由于时效性,杀毒软件无法快速的响应一些新病毒以及新木马,所以还是要保持良好的下载习惯。 定时清理电脑内的垃圾 可以定期清理电脑上下载的不用的文件,以及及时清理回收站来保证磁盘空间充足。 当长时间使用例如 QQ 微信之类的软件时,会有产生很多的数据,可以通过软件自带的清理软件来清理这部分数据,但是请注意清理这些数据时,可能会删除您的消息记录,以及一些重要的文件,请清理之前及时备份。 使用 火绒 自带的垃圾清理功能,及时清理系统以及软件的缓存,来保证磁盘充足。 及时关闭不使用的软件 在软件的使用过程中,由于电脑内存的不足造成的卡顿也是很重要的原因之一。 当电脑物理内存不够大,并且后台挂了一堆软件时,内存占用常常高于80%,此时系统因为无足够的内存来运行软件,而造成软件使用的卡顿,以及系统的卡顿。可以通过任务管理器查看哪些任务占用了过多的内存,通过结束任务,来及时释放内存保证系统的流畅。 整理桌面上的快捷方式以及文件 保持桌面整洁,不要堆积大量图标和文件。合理组织文件夹和文件,使用清晰的命名,这样可以更快速地找到所需的内容。 关于快捷方式可以通过放到下方的任务栏来快速启动应用。 关于文件,可以使用文件夹分类,来快速找到所需文件,这样也方便管理。 软件的选择 首先要说的是,大多数情况下,请不要使用国内如 腾讯、360、金山之类公司提供的可替代的工具类的软件,这些软件充斥着广告,而且非常吃系统资源。 在文末我会归类推荐一些我日常所使用的部分类型的软件,可能并非是最好用的,但是肯定是非常不错的。 推荐软件 推荐软件主要因为很多人还在使用包含很多垃圾广告而且十分吃资源的应用。 浏览器:Chrome、Edge 杀毒软件:火绒 软件卸载软件:Geek Uninstaller 下载软件:Internet Download Manager (收费)

2023/9/1
articleCard.readMore