分类: 服务器

  • 如何为wordpress的文章添加阅读量

    要在 WordPress 上实现文章阅读统计(跟踪每篇文章的阅读次数或页面浏览量),可以借助插件或自定义代码。以下是几种常见的方法和工具,如果使用代码请注意文章内容。

    方法一:使用插件实现文章阅读统计

    1. MonsterInsights
      • MonsterInsights 是最受欢迎的 Google Analytics 插件之一,可以直接在 WordPress 仪表板中查看每篇文章的页面浏览量、访客行为、跳出率等数据。通过其 Page Insights 扩展,还可以查看单篇文章的详细统计(如页面浏览量、停留时间等)。必须绑定GA。
    2. WP Statistics
      • WP Statistics 是一个隐私友好的分析插件,符合 GDPR 要求,无需外部账户,直接在 WordPress 数据库中存储数据。它可以跟踪每篇文章的访问量,并提供详细的图表和分类分析。不过最顶上那个评论似乎说明了一些问题,我没尝试这个插件,观望一下。
    3. Post Views Counter
      • 一个轻量级插件,专门用于显示文章、页面或自定义内容的浏览次数。它支持通过 PHP、JavaScript 或 REST API 跟踪数据,并允许自定义计数器的显示位置和样式。
    4. Jetpack Stats
      • Jetpack 的统计模块提供文章的浏览量、热门内容、流量来源等数据,适合 WordPress.com 用户或安装了 Jetpack 的自托管站点。免费用户可查看过去 7 天的统计,付费计划解锁更多功能。
    5. Independent Analytics
      • 一个专为 WordPress 设计的免费分析插件,加载速度快,符合 GDPR。它可以自动记录文章的访问量,并按类别显示统计数据。
    6. 如果你恰好财力雄厚,你可以使用一些主题的pro版本自带的功能
      • 这里就不对赘述了,例如我使用的blocksy主题,在设置页面左侧点击blocksy,设置中文章元数据打开显示即可。

    方法二:插件之短码插件(推荐)

    1. Post Views for Jetpack
      • 提供短码,可以在文章、页面或小工具中显示各种统计数据。以下部分代码复制于这个插件的讨论区: https://wordpress.org/support/topic/way-to-display-views-in-blocksy-post-meta/

    这个插件如何在blocksy中使用?请在你的function.php中添加以下代码 (注意把[sbs_views] 修改为你上面短码插件中约定的短码):

    add_filter( 'blocksy:archive:render-card-layer', function ( $output, $single_component) {
    	if ( 'post_meta' !== $single_component['id'] ) {
    		return $output;
    	}
    	$post_views = do_shortcode( '[sbs_views]' );
    
    	$output = str_replace( '</li></ul>', '</li><li class="post-views">' . $post_views . '</li></ul>', $output );
    	return $output;
    }, 11, 2 );

    方法三:自定义代码实现阅读统计

    在你的主题的function.php中添加以下代码:

    // 记录文章浏览量
    function set_post_views($postID) {
        $count_key = 'post_views_count';
        $count = get_post_meta($postID, $count_key, true);
        if ($count == '') {
            $count = 0;
            delete_post_meta($postID, $count_key);
            add_post_meta($postID, $count_key, '0');
        } else {
            $count++;
            update_post_meta($postID, $count_key, $count);
        }
    }
    
    // 在单篇文章页面记录浏览量
    function track_post_views($postID) {
        if (!is_single()) return;
        if (empty($postID)) {
            global $post;
            $postID = $post->ID;
        }
        set_post_views($postID);
    }
    add_action('wp_head', 'track_post_views');
    
    // 显示文章浏览量
    function get_post_views($postID) {
        $count_key = 'post_views_count';
        $count = get_post_meta($postID, $count_key, true);
        if ($count == '') {
            delete_post_meta($postID, $count_key);
            add_post_meta($postID, $count_key, '0');
            return "0 Views";
        }
        return $count . ' Views';
    }

    在需要使用的地方添加:

    echo get_post_views(get_the_ID());

    如果需要在blocksy主题中使用:

    add_filter( 'blocksy:archive:render-card-layer', function ( $output, $single_component ) {
        if ( 'post_meta' !== $single_component['id'] ) {
            return $output;
        }
    
        $output = str_replace( '</li></ul>', '</li><li class="post-views">' . get_post_views(get_the_ID()) . '</li></ul>', $output );
        return $output;
    }, 10, 2 );

    注意上面所有的代码部分,可能会造成不可回溯的内容。

    部分可能会在你数据库的前缀_postmeta表中创建很多key为post_views_count 的数据,介意的话可以使用第三方插件或者自己手动修改。另外注意,有的主题不允许修改functions.php的代码,你复制代码保存失败时,可以按 ctrl+ shift + v 粘贴。

  • 从Typecho安全平移到WordPress

    这里不比较Typecho与Wordpress的好坏。实际上优缺点都很明显。但如果你没有其他想法,只是想单纯写写内容,Notebook才是最棒的选择。我只是想把加的各位朋友的友链放在除了友链页以外的其他页面,那貌似只能放在sidebar了,所以选择了一个双栏的杂志主题。后来想了想,直接换wordpress得了。

    1. 导出数据

    数据导出当然使用的是ByTyp,但是我记得之前第一次安装是有什么问题的,貌似是PHP版本不对还是什么东西,忘记了,不过我记得我修改了一些东西。如果你会有这个问题并且你发现搜索不到解决方案,你可以点下面的按钮下载我的备份:

    2. 备份

    备份你需要做以下备份

    • 下载Typecho的所有文件内容
    • 下载Typecho的数据库备份文件
    • 尝试新建数据库并导入数据库备份文件查看是否可以导入
    • 使用Typecho的备份功能下载备份文件
    • 检查以上备份

    3. 安装Wordpress和导入数据

    因为我后端使用的是宝塔,所以有一键部署。我的域名是banzhuanriji.com,我新建的网站绑定的域名为abc(这里你自己设置).banzhuanriji.com,然后所有的操作都是在这个网站上进行的。

    工具-导入-立即安装,安装完成后会显示【运行导入器】,然后选择上面ByTyp导出的文件即可,选择接受用户即可。

    4. 修改域名

    1. 检查上面的备份内容
    2. wordpress后台,设置-常规:WordPress 地址(URL)和 站点地址(URL)修改为你的地址
    3. 修改网站文件夹名称,也就是删除原来的 banzhuanriji.com,把abc.banzhuangriji.com,修改为banzhuanriji.com
    4. 重启Nginx

    5. 安装需要的插件

    我是所有都设置好之后才修改域名的,现在我点击主题的自定义,就会先显示几条错误提示,再显示自定义网页页面。错误内容如下:

    
    Warning: Undefined array key "mp_featuredimg_1" in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 1130
    
    Warning: Trying to access array offset on value of type null in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 1130
    
    Warning: Undefined array key "mp_featuredimg_1" in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 1131
    
    Warning: Trying to access array offset on value of type null in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 1131
    
    Warning: Undefined array key "mp_featuredimg_1" in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 603
    
    Warning: Trying to access array offset on value of type null in /www/wwwroot/banzhuanriji.com/wp-includes/class-wp-customize-widgets.php on line 603

    貌似是Blocky插件的问题,到现在我都不知道怎么解决…

    6. 其他

    关于安装的插件和主题,有兴趣的话可以查看关于页面。

    如果你没有想使用Wordpress,那么我推荐你使用Tp2MD,可以导出到Markdown文件,你经过简单的修改可以直接在一些hexo,hugo,nextjs或者astro等可以使用Markdown文件的博客系统。

  • 堵不如疏,用LLMS.TXT对ai爬虫进行引导

    最近发现网站访问量异常。脚标的“当前浏览次数”数字异常。看了一下后台数据貌似是被刷流量了?搜索了一下ip才发现是被ai爬虫爬的。吐槽一下阿里云的ECS,CPU到70%就直接卡死了。面对ai爬虫,2C2G的小机感觉压力好大。想起来之前读的ruanyifeng的 科技爱好者周刊(第 343 期):如何阻止 AI 爬虫 ,里面提到了两种防止ai爬虫的方案:

    • Cloudflare
    • Anubis

    其中Anubis的逻辑大概是:

    页面会在用户的浏览器上,执行一段 JS 程序,进行大量的数学计算。直到计算答案正确,才可以访问目标网站。

    这个过程有时很耗时,可能需要1~2分钟。
    ……
    那么,Anubis 到底让爬虫计算什么?

    具体来说,就是下面这行代码,计算一个哈希值。

    const hash = await sha256(${challenge}${nonce});

    可以看到,它就是用 SHA256 算法,计算一个字符串的哈希值。

    这个字符串由两部分组成,第一部分challenge,由用户的一些公开信息连接而成,包括用户的 IP 地址、浏览器 user-agent 字段、当前日期、Anubis 的公钥等。

    第二部分nonce,表示迭代次数,第一次计算就是1,第二次计算就是2,以此类推。

    Anubis 的默认设定是,计算出来的哈希值的前五位必须都为0,否则 nonce 自动加1,再次进行计算,直到满足要求为止。

    有时,可能需要计算几百万次,才能得到合格的哈希值。熟悉比特币的同学,应该一眼看出来了,这就是比特币的算法。比特币是非常耗费算力的,所以 Anubis 也能很有效地消耗爬虫的 CPU。

    但是这对一个个人网站实在太无厘头了!文章最开始提到了使用robots.txt来拒绝爬虫,但貌似AI的爬虫都不遵守robots.txt的内容… 经过我的搜索了解,我找到了llms.txt ,你可以理解为这是面对ai的robots.txt ,它可以大幅度减少ai爬虫对资源的无意义消耗。这里是本站点的 LLMs.txt

    下面我讲简单介绍一下llms.txt,以及如何使用它。


    llms.txt 的作用

    llms.txt 似乎是一种新兴的网站标准,旨在为大型语言模型(LLMs)提供一个简洁的总结,帮助它们快速获取网站的核心信息。它通常是一个 Markdown 文件,放在网站根目录(如 /llms.txt),包含网站的背景、指南和指向详细文档的链接。这对于 LLMs 来说非常有用,因为它们的上下文窗口有限,无法处理整个网站的复杂 HTML 结构。研究表明,它特别适用于需要快速访问技术文档和 API 的场景,如软件开发环境。

    如何使用 llms.txt

    对于网站所有者,可以按照以下步骤创建和使用 llms.txt:

    • 创建文件: 在网站根目录创建一个名为 llms.txt 的文件,使用 Markdown 格式编写。
    • 添加内容: 包括标题(H1)、摘要(使用 blockquote)、可选的详细部分和链接。例如:
    # My Website
    
    > This is a brief summary of what my website offers.
    Here are some key points:
    - It provides [API documentation](https://example.com/api.md)
    - It includes [tutorials](https://example.com/tutorials.md)
    • 提供 Markdown 版本: 为关键页面提供 Markdown 版本,通过在 URL 后加 .md 实现。
    • 使用工具: 可以利用如 llms.txt 生成器 自动生成文件,简化过程。

    对于 LLMs,系统会检查网站是否有 /llms.txt 文件,并使用其中的信息快速了解网站,通过链接找到更多详情。

    关于周边

    为什么我上面会提到大幅度减少呢?因为这是一个新的民间协议,是一个新生的,约定俗成的内容。面对蓬勃发展的ai产业,很多产品经理不会要求自家ai爬虫遵守规则的。

    llms.txt 是一种 2024 年 9 月由 Jeremy Howard 提出的网站标准,旨在增强大型语言模型(LLMs)对网站内容的理解和利用,特别是在推理阶段。其设计初衷是解决 LLMs 上下文窗口有限的问题,使其能够高效处理网站信息,而无需解析复杂的 HTML 结构。

    llms.txt 的主要作用是为网站提供一个结构化、简洁的 LLM 友好内容入口。证据倾向于认为,它通过提供简短的摘要、背景信息和链接,帮助 LLMs 快速了解网站的目的和内容,避免处理复杂的网页元素如导航、广告和 JavaScript。这对于 LLMs 来说尤为重要,因为它们的上下文窗口通常无法容纳整个网站的全部内容。

    使用方法与结构

    对于网站所有者,创建和使用 llms.txt 的方法如下:

    创建文件:

    • 在网站根目录创建一个名为 llms.txt 的文件。
    • 使用 Markdown 格式编写,确保内容适合人类阅读,也适合 LLMs 解析。

    文件结构:

    • 标题(H1):必须包含项目或网站的名称,例如 # 搬砖日记
    • 摘要:使用 blockquote 格式提供简短描述,例如 > 白天给代码写对象,深夜给自己写日记
    • 详细部分(可选):可以包括段落或列表,但不使用额外的标题,例如:
    Here are some key points about my website:
    - It provides [API documentation](https://example.com/api.md)
    - It includes [tutorials](https://example.com/tutorials.md)
    • 文件列表(可选):使用 H2 标题分隔,包含超链接和可选说明,例如:
    ## Resources
    - [Detailed Guide](https://example.com/guide.md): Comprehensive user manual
    • “Optional”部分(可选):用于次要信息,LLMs 可以选择跳过,例如:
    ## Optional
    - [Additional Resources](https://example.com/more.md)

    如果你储存的txt文件在访问时出现中文乱码,那么你应该修改服务器配置:

    Nginx

        # Serve .txt files with the correct Content-Type
        location ~ \.txt$ {
            default_type text/plain;
            charset utf-8;    # Ensure charset is specified as UTF-8
        }

    Apache

    # Ensure the default charset is set to UTF-8
        AddDefaultCharset UTF-8
    
        # Configure specific file types with UTF-8 charset
        <FilesMatch "\.(txt)$">
            ForceType 'text/plain; charset=UTF-8'
        </FilesMatch>

    以上均为需要在配置文件中新添加的内容,请勿覆盖原有内容


    最近Github多次从多个技术层面对大陆ip/用户进行了筛选封锁,据说是被CSDN的搬空Github给整的… 无论如何,虽然我不是ai从业者,但是如果恰好有相关的朋友看到这里,我给了一些小建议:

    • 在访问网站时,首先检查是否存在 /llms.txt 文件。
    • 使用文件中的信息快速了解网站的目的,并通过提供的链接找到详细内容,例如 API 文档或教程。
    • 可以结合工具如 llms_txt2ctx 解析文件,生成适合 LLMs 的上下文。

    毕竟前台页面是给人看的。如果有winwin的方案,何乐而不为呢?

  • HTTP状态码全指南

    一、状态码分类逻辑

    HTTP状态码按首位数字分为5类,构成Web通信的「响应语言」:

    • 1xx:信息性状态(协议处理中)
    • 2xx:成功状态(请求已达成)
    • 3xx:重定向状态(资源位置变更)
    • 4xx:客户端错误(请求不合法)
    • 5xx:服务端错误(服务器处理失败)

    这种分类方式让开发者能快速定位请求问题的大致方向,极大提升调试效率。

    二、全量状态码速查表

    1xx Informational(信息响应)

    状态码 名称 典型场景 补充说明
    100 Continue 客户端应继续发送请求体 常用于大文件上传,先确认服务器接收意向
    101 Switching Protocols 服务器同意升级协议(如WebSocket) 需在请求头中指定Upgrade字段
    102 Processing 服务器正在处理但未完成 多用于WebDAV协议下的复杂操作

    2xx Success(成功响应)

    状态码 名称 关键特性 常见应用场景
    200 OK 标准成功响应 GET请求成功返回数据
    201 Created 资源创建成功(POST返回新URL) 接口创建用户、商品等资源时使用
    202 Accepted 请求已接收但未处理完 异步任务提交(如文件上传排队)
    204 No Content 响应体为空(如DELETE成功) 删除资源后,减少不必要的数据传输

    3xx Redirection(重定向)

    状态码 名称 缓存行为 方法保留规则 适用场景
    301 Moved Permanently 永久缓存 GET可能变HEAD 网站域名更换、页面永久迁移
    302 Found 临时缓存 方法可能改变 登录成功后跳转首页
    307 Temporary Redirect 不缓存 强制保留原始方法 临时维护页面跳转
    308 Permanent Redirect 永久缓存 强制保留原始方法 API接口版本永久变更

    4xx Client Error(客户端错误)

    状态码 名称 高频触发场景 修复建议
    400 Bad Request 请求语法错误 检查参数格式、请求头完整性
    401 Unauthorized 未提供有效身份凭证 添加认证信息(如Token、Basic Auth)
    403 Forbidden 权限不足(如访问私有文件) 确认用户角色权限配置
    404 Not Found 资源不存在 检查URL路径或资源删除逻辑
    429 Too Many Requests 触发速率限制 调整请求频率或申请更高配额

    5xx Server Error(服务端错误)

    状态码 名称 故障类型 排查方向
    500 Internal Server Error 未分类的服务器错误 检查服务器日志、代码异常捕获
    502 Bad Gateway 上游服务器无响应 确认网关配置、后端服务健康状态
    503 Service Unavailable 主动停机维护/过载 查看维护公告、扩容服务器资源
    504 Gateway Timeout 上游服务器响应超时 优化网络配置、增加超时重试机制

    三、关键场景实战指南

    1. SEO优化组合拳

    • 301+308:永久迁移时保留链接权重
    • 429+Retry-After:应对爬虫时友好限流

    2. API设计黄金法则

    GET /api/users/1 HTTP/1.1
    -> 200 OK(成功)
    -> 404 Not Found(资源不存在)
    -> 410 Gone(资源已删除且无新地址)

    3. 错误处理最佳实践

    • 4xx错误必须返回清晰错误详情(如JSON Body)
    • 5xx错误应记录完整日志链(Request-ID追踪)

    四、冷知识彩蛋

    ​​418 I’m a teapot​​:源自HTTP愚人节RFC(真实存在于某些库中)
    ​​206 Partial Content​​:支持断点续传的核心状态码

  • 一些免费的图床整理和对比

    因为我有SM.MS账号,所以一直是登录使用。最近才发现SM.MS禁止了游客上传图像,今天试的imgdd上传出现了问题。正好闲来无事整理一下现在可用的免费图床。

    图像处理:

    https://ic.yunimg.cc/

    可选择多种文件尺寸和图像质量,并可在线预览对比图像质量后保存。

    https://imagestool.com/webp2jpg-online/

    几乎全能图像在线转换压缩处理工具

    图床

    以下为图床列表,示例图片文件大小为1.01Mb左右(1041 kb,1065532 字节),你可以按F12,在开发人员工具中选择网络-停用缓存,然后按F5刷新页面,查看图片下载速度。

    只做收集使用,没有任何利益关系。请注意备份您的数据

    (更多…)

  • 修改Typecho的登录路径

    为了防止有奇怪的人不断试你的密码,你可以尝试修改你的Typecho的登录路径。

    以下举例,我们将admin修改为SAVq87NqJ9ecUSYl

    需要修改的文件夹

    1. 打开网站文件根目录
    2. 重命名文件夹adminSAVq87NqJ9ecUSYl

    需要修改的配置

    1. 打开根目录config.inc.php文件,修改大约第12行的
    define('__TYPECHO_ADMIN_DIR__', '/admin/');
    1. 打开install.php(如果已经完成网站安装,可忽略),大约第14行已经第405行
    define('__TYPECHO_ADMIN_DIR__', '/admin/');

    将移上所有的admin修改为SAVq87NqJ9ecUSYl即可。

  • 冷饭加鸡肋,越炒越无味

    2025年3月14日更新:

    没想到ruanyifeng这周和我写一个话题的内容。

    https://www.ruanyifeng.com/blog/2025/03/weekly-issue-341.html

    TL;DR

    我不认为低代码平台+ai会变香


    最近在 X 上又刷到有人吹低代码平台,说它“未来可期”。作为一个写了十几年代码的老程序员,我实在忍不住想吐槽。2025 年 3 月的今天,低代码仍然在炒,但我怎么看都觉得它像个老掉牙的故事——多年前就有人做过,有人退场,活下来的也没多风光。开发者真要为它担心失业?我看未必。

    低代码的炒作历史

    低代码并不新鲜。十年前就有一堆“零代码”“低代码”平台冒出来,喊着“拖拖拽拽就能做应用”。OutSystems、Mendix 这类老面孔仍在,国内也涌现了不少平台,但看看,有多少已经悄无声息地退出了市场?活下来的,像 Appian 或者钉钉宜搭,日子也不算滋润。我认识一哥们儿用低代码搭了个库存系统,业务一调整就改不动,最后还是找我重写。

    根据Gartner 2024年报告,全球低代码市场规模增速已从2021年的23.6%下降至7.2%

    Forrester 报告中的结论:低代码项目平均维护成本比传统开发高 2.3 倍。

    AI的加入与现实

    最近,低代码平台开始加入 AI,宣传上功能似乎变强了,能自动生成 UI、调优逻辑等。听起来很吸引人,但我一想,这不扯吗?“好用”不是一开始就该有的吗?AI 是新添的没错,但作为一个开发工具,基础功能好用才是最基本的要求。加了 AI 就吹得天花乱坠,好像以前不好用是理所当然似的。更别提 AI 生成的内容,改起来还是老样子——要么直接用,要么手动调整,跟十年前改代码没啥两样。AI 救不了低代码的命,最多也就是个噱头。

    对开发者的影响

    有人说低代码抢初级开发者的饭碗。确实,简单的表单和内部工具能拖几下搞定,初级程序员可能有点压力。但对我这种习惯复杂逻辑的人来说,低代码根本动不了我。那些“80% 简单需求”它能凑合,剩下 20% 的高性能、高定制化活儿,还得靠我们。

    低代码还老给我添乱。客户用它搞个半成品,跑来让我修 bug、调性能,比从头写还费劲。我见过公司拿低代码做了个原型,上线后卡得要死,最后还得重构。省了点时间,却留下一堆烂摊子,这算啥“革命”啊?

    收费模式的高数题

    再说说低代码的收费模式,真是让人无语。免费版的基础功能弱得可怜,比如最多建几个表、连个像样的 API 都不行,想干点正事儿就得掏钱。收费功能层级森严,基本每个平台都有“基础版”“专业版”“企业版”之类的分级,价格一级比一级离谱。举个例子,我试过一个平台,免费版连导出数据都不行,想加个自定义插件,得升到每月几百块的专业版。更别提什么“无限用户”“高级支持”了,全锁在最贵的套餐里。这哪是工具啊,简直是圈钱的套路机器。

    未来?别指望它翻天

    低代码的粉丝总爱说未来会更智能,靠 AI 翻身。我听了只想笑。AI 是牛,但低代码加了 AI 就能写分布式系统?能优化算法?我看悬。这么多年,低代码的套路我都看透了:炒一波概念,忽悠一波企业用户,然后慢慢淡出视线。活下来的,要么靠大厂撑腰(比如微软的 Power Apps),要么苟在小众市场,风光不到哪去。

    什么“低代码 + 传统开发共存”的说法,我也懒得信。企业用低代码无非图快图便宜,可业务一复杂,它就成鸡肋,重写成本还更高。我宁可从头写个扎实的系统,省得回头返工。

    结论:低代码的未来

    在我眼里,低代码就是个“伪命题”。炒了这么多年,没真干掉谁,也没见哪个平台成了行业霸主。加个 AI 也救不了它,免费功能鸡肋,收费还一套一套的。开发者要失业?除非你只会写“Hello World”。对我来说,低代码顶多是个玩具,玩玩行,想靠它吃饭,我看悬。

    所以,别被低代码的宣传唬住了。想在这行混好,还是老老实实练功——算法、架构、DevOps,这些真本事才是我们的护身符。低代码?让它继续炒吧,我码我的代码。

  • 免费静态托管服务对比

    在当今的网络环境中,静态网站托管服务变得越来越流行,尤其是对于开发者和博客作者来说。本文将介绍三种流行的免费静态网站托管服务:Vercel、GitHub Pages 和 Cloudflare Pages,并对它们的免费服务进行比较。

    Vercel

    Vercel 是一个专注于前端开发的托管平台,提供快速、可靠的静态网站托管服务。它的主要特点包括:

    • 全球 CDN:Vercel 在全球范围内拥有多个 CDN 节点,确保网站的快速加载。
    • 自定义域名:支持用户使用自定义域名,并提供自动部署功能。
    • 构建限制:每月带宽限制为 100GB,构建次数和构建时长也有限制,但整体上对个人用户来说相对宽松。
    • 速度:在国内访问速度较快,通常比 GitHub Pages 和 Cloudflare Pages 更具优势。

    GitHub Pages

    GitHub Pages 是 GitHub 提供的静态网站托管服务,适合开发者和开源项目。其特点包括:

    • 稳定性:作为全球最大的代码托管平台,GitHub Pages 的稳定性相对较高。
    • 自定义域名:支持用户使用自定义域名。
    • 访问速度:在国内访问速度一般,偶尔会出现访问问题。
    • 限制:每月流量限制为 100GB,单个文件大小限制为 100MB,仓库大小建议少于 5GB。

    Cloudflare Pages

    Cloudflare Pages 是 Cloudflare 推出的静态网站托管服务,旨在提供快速和安全的网站托管。其特点包括:

    • 全球 CDN:同样拥有全球 CDN 节点,确保快速加载。
    • 自定义域名:支持最多 10 个自定义域名。
    • 构建限制:每月可构建 500 次,文件数量限制为 2万,单个文件大小不得超过 25MB。
    • 速度:与 GitHub Pages 相似,但在国内的访问速度和稳定性一般。

    免费服务对比

    在比较这三种服务时,可以从以下几个方面进行分析:

    1. 访问速度

      • Vercel 的访问速度在国内表现最佳,通常比 GitHub Pages 和 Cloudflare Pages 更快。
      • GitHub Pages 和 Cloudflare Pages 的速度相似,但 GitHub Pages 的稳定性更好。
    2. 自定义域名支持

      • 三者均支持自定义域名,但 Cloudflare Pages 对域名数量有上限(最多 10 个)。
    3. 构建和流量限制

      • Vercel 每月带宽限制为 100GB,构建次数和时长有限制。
      • GitHub Pages 每月流量限制为 100GB,文件和仓库大小也有相应限制。
      • Cloudflare Pages 每月可构建 500 次,文件数量和大小限制较为严格。
    4. 适用场景

      • Vercel 适合需要快速加载和高稳定性的个人博客或项目。
      • GitHub Pages 适合开源项目和开发者,尤其是对百度收录有需求的用户。
      • Cloudflare Pages 适合需要使用 Cloudflare CDN 的用户,但在国内的表现可能不如 Vercel。

    结论

    综合来看,Vercel 是一个非常适合个人博客和前端项目的托管平台,尤其是在国内访问速度方面表现突出。GitHub Pages 则是一个稳定的选择,适合开源项目和开发者。Cloudflare Pages 虽然提供了强大的 CDN 支持,但在国内的访问速度和稳定性相对较弱。根据个人需求选择合适的平台,将有助于提升网站的访问体验。


    如果你想试一下你所在的地区访问各服务的速度,你可以使用以下数据

    无域名,平台部署测试域名访问

    域名访问,由Cloudflare进行DNS解析,无CDN

    以上引用内容来自:https://github.com/hoytzhang/static-pages-test
    你可以使用 https://www.itdog.cn/http/ 来进行访问对比

  • 互联网没有DELETE

    在现代 Web 应用的交互场景中,数据删除操作是用户与系统频繁互动的功能之一。当用户轻松点击 “删除” 按钮时,背后实则是一系列环环相扣、复杂精妙的技术流程在运转。而且,多数情况下,内容并不会真正从服务器上消失,只是被标记为不可见,依然留存在服务器的数据仓库中。本文将深入剖析这一过程及其背后的多重考量。

    一、前端触发:点击背后的初始响应

    (一)前端事件捕获

    当用户在网站界面点击 “删除” 按钮时,前端的 JavaScript 脚本迅速响应,如同训练有素的哨兵。它会利用事件监听机制,如 addEventListener 方法,精准捕捉这一点击事件。为了避免用户误操作,通常会弹出确认对话框,以友好的提示询问用户是否真的要删除该项内容。这个对话框就像是一道安全闸门,为可能的误删操作设置了一道防线。

    (二)请求发送

    若用户确认删除,前端会借助 AJAX(Asynchronous JavaScript and XML)或者 Fetch API 发起一个 HTTP 请求。按照 RESTful API 的设计规范,这个请求一般采用 DELETE 方法。请求中会携带要删除资源的唯一标识符,如数据库中的主键 ID 或者 UUID,它就像是一把钥匙,能让后端准确找到要处理的数据。

    二、后端承接:请求的接收与精细处理

    (一)路由匹配

    后端服务器接收到前端发送的请求后,首先会根据请求的 URL 和 HTTP 方法进行路由匹配。这就好比在一个大型图书馆中,根据书籍的分类标识和借阅规则,快速定位到负责处理该请求的具体函数。通过精确的路由匹配,请求被导向相应的处理逻辑。

    (二)请求验证

    在正式处理请求之前,后端会进行严格的验证工作。这包括用户身份验证,通过检查用户的登录凭证、令牌等信息,确保请求来自合法的用户;同时还会进行数据验证,检查请求中携带的数据格式是否正确、是否符合业务规则。只有通过这一系列严格的验证,请求才会被允许继续处理。

    (三)核心删除操作

    这是整个删除流程的关键环节。虽然用户直观感觉数据已被删除,但实际情况存在两种不同的处理方式:

    • 逻辑删除:这是更为常见的处理方式。后端会在数据库中对数据进行标记,通常是通过设置一个名为 is_deleted 的字段。将该字段的值设置为特定标识(如 true1),表示数据已被删除。此时,数据在物理上仍然完整地保留在数据库中,只是在后续的查询操作中,会通过 SQL 语句的 WHERE 条件过滤掉这些标记为已删除的数据,从而对普通用户不可见。
    • 物理删除:直接从数据库中永久移除数据。这种方式相对较少使用,尤其是在需要考虑数据恢复的业务场景下。因为一旦执行物理删除,数据将难以恢复,可能会给业务带来不可挽回的损失。

    (四)后续操作跟进

    删除操作完成后,后端可能会执行一些后续操作来确保系统的一致性和可追溯性。例如,更新缓存以保证数据的实时性,避免用户看到旧的数据;同时记录审计日志,详细记录删除操作的执行者、执行时间、被删除的数据等信息,为后续的数据分析和安全审计提供依据。

    三、结果反馈:后端到前端的信息传递

    (一)响应状态返回

    后端完成处理后,会返回一个 HTTP 状态码给前端。例如,返回 200 OK 表示操作成功;若出现错误,会返回相应的错误状态码,如 400 Bad Request 表示请求参数有误,403 Forbidden 表示用户没有权限进行该操作等。这个状态码就像是一个信号旗,向前端传达操作的基本结果。

    (二)详细反馈信息

    除了状态码,后端还会返回详细的消息,进一步告知用户删除操作的具体结果。例如,“删除成功” 或者 “由于 XX 原因,删除失败” 等信息,让用户清楚了解操作的最终情况。
    四、前端呈现:用户体验的优化与更新

    (一)界面更新

    前端接收到后端的响应后,会根据响应状态对用户界面进行更新。如果删除操作成功,通常会从视图中移除已标记为删除的数据项,让用户直观看到数据已被删除。这一过程就像是舞台上的演员退场,界面变得更加简洁。

    (二)用户体验提升

    为了提升用户体验,前端会采取一系列优化措施。比如,在请求发送过程中显示加载指示器,让用户知道系统正在处理请求,避免用户因长时间等待而产生焦虑;操作完成后提供确认消息,给予用户明确的反馈;甚至还可以提供可选的撤销操作,允许用户在一定时间内反悔,恢复刚刚删除的数据,增加用户操作的灵活性和安全感。

    五、数据留存:不消失的背后逻辑

    (一)数据恢复保障

    逻辑删除的方式为数据恢复提供了便利。在用户误操作删除数据后,可以通过简单的操作,如将 is_deleted 字段的值改回原来的状态,轻松恢复数据。这就像是给数据加了一个 “后悔药”,避免了因误删造成的信息丢失,保障了数据的安全性和完整性。

    (二)数据分析与合规审计

    保留数据对于企业的数据分析和审计工作具有重要意义。通过对历史数据的分析,企业可以了解用户行为、业务趋势等信息,为决策提供有力支持。同时,在一些行业中,法规要求企业保留一定期限的业务数据,以便进行合规审计。逻辑删除可以满足这一需求,确保企业在不影响正常业务操作的前提下,能够顺利通过审计。

    (三)存储性能优化

    逻辑删除可以减少频繁的物理删除操作,从而提高数据库的性能。物理删除操作会导致数据库产生碎片,影响数据的读写效率。而逻辑删除只是对数据进行标记,不会对数据库的物理结构造成实质性的改变,减少了数据库维护的成本和复杂度。

    六、安全防线:保障删除操作的可靠性

    (一)身份验证与授权管理

    在实现删除功能时,确保只有经过身份验证的用户才能进行操作是至关重要的。通过用户登录系统时的身份验证机制,如用户名和密码、OAuth 认证等,确定用户的合法性。同时,根据用户的角色和权限,精确控制用户能够删除的数据范围,防止越权操作。

    (二)CSRF 攻击防护

    为了防止跨站请求伪造(CSRF)攻击,系统会使用 CSRF 令牌。在用户登录或页面加载时,服务器会生成一个唯一的 CSRF 令牌,并将其嵌入到页面中。当用户发起删除请求时,前端会将该令牌一并发送给后端。后端会验证该令牌的有效性,只有令牌合法的请求才会被处理,从而确保请求的来源是合法的,避免恶意网站伪造请求。

    (三)确认机制强化

    在用户执行删除操作之前,提供明确的确认提示是防止误删除的有效手段。除了前端弹出的确认对话框,还可以在后端进行二次确认,确保用户的删除意图是真实的。例如,要求用户输入密码或验证码等额外信息,进一步提高删除操作的安全性。

    七、总结

    当我们在网站上轻点删除按钮时,背后隐藏着一个复杂而精密的技术世界。尽管表面上数据似乎已被删除,但实际上它往往只是被标记为不可见,仍然静静地存留在服务器上。这种逻辑删除的方式为数据管理带来了极大的灵活性,既避免了误删除带来的困扰,又满足了数据恢复、分析和审计等多方面的需求。通过深入理解删除操作背后的机制,开发者可以更好地设计和实现安全、高效的删除功能,为用户提供更加优质的服务体验。希望本文能为你的开发实践提供有价值的参考,让你在处理数据删除问题时更加得心应手。