有的没的
【Vercel】为什么推送了提交之后,网站没有自动部署?

在Vercel上,每次向Github项目push时会自动部署,免费账户每天限100次。公共库的所有PR都会触发部署,但私有库仅限团队成员的推送。判断依据是提交者的邮箱地址,需确保与Vercel团队成员邮箱匹配。要修改git邮箱,可参考相关配置文章,然后在Vercel后台邀请用户加入团队。
通常,在 Vercel 上部署了一个 Github 上的项目,每次 git push 的时候,就自动触发部署,Vercel 把部署过程做得很丝滑。如果频繁提交,还要注意不要超过部署额度,免费账户每天的部署次数最多100次。

对于 Github 上的公开库,任何人推送或合并 PR,都将触发自动部署。但对于私有库,只有 Vercel 上团队成员的推送才会触发自动部署。也就是说,非团队成员推送提交到私有库,不会触发自动部署。

Vercel 怎么判断一个推送提交者是不是团队成员呢?唯一的判断是改提交用户的邮箱地址。如何修改git用户邮箱地址,可以参考这篇文章:【git】配置邮箱地址及用户名。

修改好git用户邮箱之后,就可以在 Vercel 项目管理后台,邀请用户加入团队。

#programming
vercel太坑爹了!!integration 页面提供的 upstash-kv 的 token 都不对!!

最后还是点一下“Open in upstash" 跳转到 upstash 官网,那上面提供的 token 是对的。

#programming
主流 AI 提示词优化工具推荐(2025 全面对比指南)

via 掘金人工智能本月最热 (author: 一点一木)



#bm #ai
Vercel 的 rewrites 在这两种情况下的行为是不同的:

---

### 情况一:静态路径重写 (没有使用正则表达式捕获)

这是您最开始的例子:

"rewrites": [
  {
    "source": "/w",
    "destination": "/api/index"
  }
]


* 行为: 这种配置像一个**别名**。你告诉 Vercel:“/w 这个路径就是 /api/index 的一个别名”。
* `request.url`: 当请求到达时,Vercel 查找这个别名,然后把请求完全交给 /api/index 处理。此时,对于 api/index 函数来说,它看到的 request.url 就是它自己的地址:`/api/index`。原始的 /w 在这个阶段已经被“翻译”掉了。

---

### 情况二:动态路径重写 (使用正则表达式捕获)

这是您的第二个例子:

"rewrites": [
  {
    "source": "/(.*)",
    "destination": "/api/index.js"
  }
]


* 行为: 这种配置像一个**前端控制器**或**网关**。`/(.*) 中的 (.*) 是一个正则表达式的“捕获组”,它会捕获所有传入的路径。你告诉 Vercel:“无论用户访问什么路径,都把它捕获下来,然后交给 /api/index.js` 这个函数去处理”。
* `request.url`: 为了让 /api/index.js 能正确处理请求(例如,根据 URL 显示不同的页面内容),Vercel 必须把**原始捕获到的路径**告诉它。因此,在这种情况下,函数内部拿到的 request.url **就是用户访问的原始 URL**。

---

### 总结

| source 的写法 | 行为模式 | 函数收到的 request.url |
| :----------------------- | :------------- | :------------------------ |
| "/w" (静态路径) | 别名 (Alias) | "/api/index" (目标地址) |
| "/(.*)" (动态正则捕获) | 网关 (Gateway) | "/w" (原始请求地址) |



#programming
这几天开发了一下vercel的无框架后端玩法,对比了一下和cf worker的不同。

其实就是多了vercel.json的一层路由,还有package.json的包定义。

用的node.js的后端,所以比cf worker强大,但是回回得compile, 需要时间。

然后kv的话可以在integration中连接别家服务。目前还没测试过。

相对来说比cf worker重不少


#programming
完成了一个 tg searcher 的小改版。
现在 json 经过压缩之后再上传到 cf r2,客户端访问的时候解压再搜索。

小 manual:

1. 在本地准备上传文件:

* 确保你的 channel_content.json 文件在电脑上。

* 打开命令行终端,进入该文件所在目录,运行 gzip 命令进行压缩:


     gzip channel_content.json
     


* 这会生成一个 channel_content.json.gz 文件。

2. 上传压缩文件:

* 使用 curl 命令上传这个 .gz 文件。注意 Content-Type 现在是 `application/gzip`。


     curl -X POST "https://<你的Worker地址>/upload?token=<你的AUTH_TOKEN>" \
          -H "Content-Type: application/gzip" \
          --data-binary "@channel_content.json.gz"
     


* --data-binary 确保文件以二进制形式上传,不会被修改。

* 成功后,你会看到 Successfully uploaded channel_content.json.gz. 的消息。


#programming
bard 是好东西!!!

ios 端可以定义推送的严重级别!如果想实现强提醒,那么就把严重级别改为 critical!!
还可以设定持续通知,不断地播放铃声直到dismiss!!
而且还可以点击推送跳转 url. 支持 url scheme! 这样可以跳转到企业微信!

此外,服务端有 cfworker 的实现,非常方便!

这样。。在校方不断给我的自动写日志爬虫设置障碍的情况下。。我不得不采用人工预定提醒的方法了

也还行吧

#programming
现在有一个问题就是在openclash绕过U D P了之后这种情况下DNS走代理的话到底管不管用

可以做一个小实验,走明文的DNS,加Proxy和不加Proxy看看是否会产生泄漏

只要不泄露的话那么就可以采用这种方法


#network
接下来的研究任务是,目前的这种走代理的解析方式的话肯定会有延迟的。
需要研究一下既然是有fake IP了, 这种方法的存在性是否还有意义。
好文章!
写了clash的dns 污染问题,以及应该怎么配,做了很多实验

https://blog.echosec.top/p/dive-into-clash-dns/

顺便收藏 clash 和 shadowrocket 的配置手册:

https://wiki.metacubex.one/config/dns/#_1

以下这个Shadowrocket的配置手册直接宝藏!
https://lowertop.github.io/Shadowrocket/
—-
dns 配置总结


国外dns用 dot cf/Googleremote(反正走 tcp,远方也能代理,也不依赖长连接)
国内dns用明文223、dnspod
节点解析用doh的223主备

#network
#network 『Blog』Dive into Clash DNS
现在使用https://1key.me 验证gemini 真方便

Google Gemini学生验证:

访问https://gemini.google/students/ 生成sheerid 的链接如https://services.sheerid.com/verify/67c8c14f5f17a83b745e3f82/?verificationId=68b8e16a57ab4b******
https://1key.me/ 打开
全局梯子到美丽国
点击开始验证按钮
排队等待执行就好了
image
重新打开https://gemini.google/students/ 页面绑定国内VISA卡信息,我用的是招商银行的
认证成功
image
记得到Google Play取消订阅,否则后面可能会自动扣款


#programming #ai Gemini voor studenten: je AI-studiepartner van Google
淘宝购tria美国家用激光脱毛仪1800元,开五档,一次500下,一周打一次,我用了半年现在已经没有胡青了,小魔女可以试一下。

silkpro也不错,次数多多了,寿命长长了!

#bm
Back to Top