跳转至内容
让每一次思考都有价值
  • 星态思社区公告

    1 1
    1 文章
    1 评论
    星态思
    您评论、发布、传播的内容应自觉遵守宪法法律、法规、遵守公共秩序,尊重社会公德、社会主义制度、国家利益、公民合法权益、道德风尚和信息真实性等要求。您同意并承诺不制作、复制、发布、传播法律、法规禁止的下列信息内容,不得自行或允许、协助任何人利用“星态思”及其相关服务从事下述行为: (1)反对宪法确定的基本原则的; (2)危害国家安全,泄露国家秘密的; (3)颠覆国家政权,推翻社会主义制度、煽动分裂国家、破坏国家统一的; (4)损害国家荣誉和利益的; (5)宣扬恐怖主义、极端主义的; (6)宣扬民族仇恨、民族歧视,破坏民族团结的; (7)煽动地域歧视、地域仇恨的; (8)破坏国家宗教政策,宣扬邪教和迷信的; (9)编造、散布谣言、虚假信息,扰乱经济秩序和社会秩序、破坏社会稳定的; (10)散布、传播暴力、淫秽、色情、赌博、凶杀、恐怖或者教唆犯罪的; (11)侵害未成年人合法权益或者损害未成年人身心健康的; (12)未获他人允许,偷拍、偷录他人,侵害他人合法权利的; (13)包含恐怖、暴力血腥、高危险性、危害表演者自身或他人身心健康内容的; (14)危害网络安全、利用网络从事危害国家安全、荣誉和利益的; (15)侮辱或者诽谤他人,侵害他人合法权益的; (16)对他人进行暴力恐吓、威胁,实施人肉搜索的; (17)涉及他人隐私、个人信息或资料的; (18)散布污言秽语,损害社会公序良俗的; (19)违反商业道德、侵害商业秘密、侵犯他人隐私权、名誉权、肖像权、知识产权等合法权益内容的; (20)散布商业广告,或类似的商业招揽信息、过度营销信息及垃圾信息; (21)使用本网站常用语言文字以外的其他语言文字评论的; (22)与所评论的信息毫无关系的; (23)所发表的信息毫无意义的,或刻意使用字符组合以逃避技术审核的; (24)涉及他人隐私、个人信息或资料的,例如,非法收集或披露个人身份信息或教育、财务或其他受保护的记录,例如地址、电话号码、电子邮件地址、个人身份证明文件中的号码和特征(例如,社会保险号码、护照号码、身份证号码)或信用卡号码; (25)其他违反法律法规、政策及公序良俗、干扰“星态思”正常运营或侵犯其他用户或第三方合法权益内容的其他信息。 涉及以上内容会被禁止发布,如有以上行为,请点击举报或致信jubao@xintest.cn,我们将第一时间处理! 详细细则请阅读:用户协议 感谢您的支持
  • 知识汇集地

    26 30
    26 文章
    30 评论
    十二
    目录1. 选项式 API(Options API)2. 组合式 API(Composition API)+ 3. 组合式 API(Composition API)+ 普通 4. 函数式组件5. 单文件组件(SFC)与 JSX 结合总结 在 Vue 3 中,定义组件主要有以下几种方式,每种方式都有其适用场景: 1. 选项式 API(Options API) 这是 Vue 2 中就存在的传统方式,通过配置对象定义组件的各种选项。 // MyComponent.vue export default { // 组件名称 name: 'MyComponent', // 数据 data() { return { message: 'Hello Vue 3' } }, // 计算属性 computed: { reversedMessage() { return this.message.split('').reverse().join('') } }, // 方法 methods: { updateMessage() { this.message = 'Updated!' } }, // 生命周期钩子 mounted() { console.log('Component mounted') }, // 模板 template: ` <div> <p>{{ message }}</p> <p>{{ reversedMessage }}</p> <button @click="updateMessage">Update</button> </div> ` } 适用场景: 迁移 Vue 2 项目到 Vue 3 简单组件或快速原型开发 团队成员更熟悉选项式 API 2. 组合式 API(Composition API)+ <script setup> 这是 Vue 3 推荐的方式,通过 <script setup> 语法糖简化组合式 API 的使用,是目前最常用的组件定义方式。 <!-- MyComponent.vue --> <template> <div> <p>{{ message }}</p> <p>{{ reversedMessage }}</p> <button @click="updateMessage">Update</button> </div> </template> <script setup> import { ref, computed, onMounted } from 'vue' // 响应式数据 const message = ref('Hello Vue 3') // 计算属性 const reversedMessage = computed(() => { return message.value.split('').reverse().join('') }) // 方法 const updateMessage = () => { message.value = 'Updated!' } // 生命周期钩子 onMounted(() => { console.log('Component mounted') }) </script> 特点: 无需显式导出组件 顶层变量和函数自动暴露给模板 更好的类型推断支持 代码组织更灵活,可按逻辑关注点拆分 适用场景: 大多数 Vue 3 新项目 复杂组件(逻辑可拆分重组) 需要更好 TypeScript 支持的项目 3. 组合式 API(Composition API)+ 普通 <script> 不使用 <script setup> 语法糖,显式通过 setup() 函数返回组件选项。 <!-- MyComponent.vue --> <template> <div> <p>{{ message }}</p> <button @click="updateMessage">Update</button> </div> </template> <script> import { ref } from 'vue' export default { name: 'MyComponent', setup() { const message = ref('Hello Vue 3') const updateMessage = () => { message.value = 'Updated!' } // 必须显式返回供模板使用 return { message, updateMessage } } } </script> 适用场景: 需要在 setup() 之外使用其他选项式 API 选项时 需要更精细控制组件导出时 4. 函数式组件 无状态、无生命周期的轻量级组件,通过函数返回虚拟 DOM。 // FunctionalComponent.js import { h } from 'vue' export default function FunctionalComponent(props) { return h('div', `Hello, ${props.name}`) } // 定义 props 类型 FunctionalComponent.props = { name: { type: String, required: true } } 在模板中使用: <template> <FunctionalComponent name="Vue" /> </template> 特点: 没有响应式状态 没有生命周期钩子 性能更好(适合纯展示组件) 适用场景: 纯展示性组件(如图标、标签) 需要高性能渲染大量相似组件时 5. 单文件组件(SFC)与 JSX 结合 Vue 3 对 JSX 有良好支持,可以在单文件组件中使用 JSX 语法。 <!-- MyComponent.vue --> <script setup lang="tsx"> import { ref } from 'vue' const count = ref(0) const increment = () => { count.value++ } // JSX 渲染函数 const render = () => ( <div> <p>Count: {count.value}</p> <button onClick={increment}>Increment</button> </div> ) export default { render } </script> 适用场景: 习惯 React 风格开发的团队 需要复杂条件渲染逻辑的组件 总结 推荐使用:<script setup> + 组合式 API(大多数场景) 兼容性需求:选项式 API(Vue 2 迁移项目) 性能敏感:函数式组件(纯展示场景) 特殊需求:JSX 或普通组合式 API
  • 汇聚思想灵光

    15 19
    15 文章
    19 评论
    精准扶贫对象
    目录一、主要安全风险二、安全防范措施1. 强化身份认证2. 严格控制端口开放3. 保护配置文件安全4. 加密传输流量5. 定期更新与监控6. 其他安全措施总结 使用 frp 进行内网穿透确实存在一定的安全风险,但通过合理配置可以有效降低风险。以下是常见的安全风险及对应的防范措施: 一、主要安全风险 未授权访问内网服务 如果 frp 配置不当(如未设置认证、端口开放过度),攻击者可能通过 frp 直接访问内网中的敏感服务(如数据库、SSH、后台管理系统等),导致数据泄露或服务器被控制。 服务端端口暴露风险 服务端的 bind_port(客户端连接端口)和 remote_port(转发端口)若直接暴露在公网且缺乏防护,可能成为扫描和攻击的目标(如端口扫描、暴力破解)。 配置文件泄露 frp 配置文件中可能包含认证 token、内网 IP、端口等敏感信息,若被泄露,攻击者可利用这些信息针对性攻击。 frp 自身漏洞 虽然 frp 安全性较高,但任何软件都可能存在漏洞(如历史版本中的权限绕过、内存溢出等),可能被利用进行攻击。 流量监听风险 默认情况下,frp 传输的流量是明文的,若在公网传输敏感数据(如登录密码),可能被中间人监听窃取。 二、安全防范措施 1. 强化身份认证 必须设置 token 认证:在服务端和客户端的 [common] 配置中添加相同的 token(建议使用复杂随机字符串),阻止未授权客户端连接。 示例:token = R8fL2xP9kS1mQ7dZ3(避免使用简单密码)。 限制客户端 IP(服务端):通过 allow_ports 或 deny_ports 限制客户端可使用的端口范围,或在 [common] 中设置 allow_ip 仅允许特定 IP 的客户端连接。 示例(服务端 frps.ini): [common] # 仅允许 192.168.1.x 网段的客户端连接(若客户端在固定IP) allow_ip = 192.168.1.0/24 2. 严格控制端口开放 最小化端口暴露:服务端仅开放必要的端口(如 bind_port、少量常用 remote_port),并在防火墙/安全组中限制端口的访问来源(如仅允许信任的 IP 访问)。 例如:SSH 穿透的 remote_port 可限制仅允许自己的公网 IP 访问。 避免使用常用端口:remote_port 尽量选择 10000 以上的高位端口,减少被扫描和攻击的概率(避免 22、80、443 等常见端口)。 禁止客户端自定义端口(服务端):通过 allow_ports 限制客户端可使用的端口范围,防止客户端滥用端口。 示例(服务端 frps.ini): [common] # 仅允许客户端使用 6000-7000 范围内的端口 allow_ports = 6000-7000 3. 保护配置文件安全 限制配置文件权限:在 Linux 系统中,将 frps.ini 和 frpc.ini 的权限设置为 600(仅所有者可读写),避免其他用户读取敏感信息。 命令:chmod 600 frps.ini。 避免明文存储敏感信息:配置文件中不写入账号密码等信息,若需使用(如控制台),应设置强密码(字母+数字+特殊字符)。 4. 加密传输流量 启用 TLS 加密:frp 支持通过 TLS 加密客户端与服务端之间的通信,防止流量被监听或篡改。 配置方法(服务端和客户端均需添加): [common] tls_enable = true # 开启TLS加密 对内网服务启用加密:若穿透的是 Web 服务,建议在服务端配置 HTTPS(通过 Nginx 反向代理 + SSL 证书),确保外网访问时的流量加密。 5. 定期更新与监控 及时更新 frp 版本:关注 frp 官方更新,修复已知漏洞(如历史版本的权限问题)。 监控 frp 运行状态:通过服务端控制台(dashboard_port)定期查看连接的客户端和转发规则,发现异常连接(如未知 IP、可疑端口)及时断开。 日志审计:开启 frp 日志(log_file、log_level = info),记录连接信息,便于事后追溯异常访问。 6. 其他安全措施 避免穿透敏感服务:尽量不穿透数据库(如 MySQL、Redis)、内网管理后台等高危服务,若必须穿透,需额外添加访问密码或限制来源 IP。 使用非 root 权限运行:在 Linux 中,以普通用户身份启动 frp(避免使用 root),降低被攻击后权限扩散的风险。 服务端防火墙加固:除必要端口外,关闭所有其他端口,可使用 ufw(Linux)或 Windows 防火墙精细化控制端口访问。 总结 frp 的安全风险主要源于配置不当,而非工具本身。只要遵循“最小权限原则”(仅开放必要服务和端口)、强化认证与加密、定期更新和监控,就能将风险控制在较低水平。对于高安全性需求场景(如企业内网),建议结合 VPN、跳板机等多重防护措施。
  • 热门资讯,关注动态

    4 4
    4 文章
    4 评论
    资讯有态度
    2025 年 10 月 5 日,谷歌通过官方渠道宣布重大服务调整:自 2026 年 1 月起,Gmail 将正式停用两项核心功能 —— 以 POP 协议检查第三方邮箱的服务,以及针对第三方账号的增强工具 Gmailify,此举旨在进一步聚焦安全性能升级与核心服务优化。 据谷歌官方说明,此次调整将直接影响两类用户场景。其一,Gmail 网页端及客户端中的 “查收其他账号的邮件” 选项将彻底下线,用户无法再通过 POP 协议将 Outlook、网易邮箱等第三方平台的邮件同步至 Gmail 收件箱;其二,Gmailify 服务终止后,关联的第三方账号将失去垃圾邮件拦截、收件箱智能分类、高级搜索运算符及优化版移动端通知等增强功能。 “这是基于协议安全性与用户体验的双重考量。” 谷歌邮件产品负责人在内部沟通中提及,POP 协议作为早期邮件同步技术,存在同步延迟、权限管控薄弱等固有缺陷,而 Gmailify 的功能逻辑与谷歌最新推出的端到端加密(E2EE)体系存在兼容性冲突。值得注意的是,Gmail 并未完全关闭第三方邮件关联通道,IMAP 协议仍将保持正常服务,用户可通过该协议实现邮件双向同步,但其功能丰富度将不及此前的 Gmailify 增强模式。 此次服务调整与谷歌近期的安全战略升级形成呼应。今年 4 月,谷歌已面向全球用户推出端到端加密邮件服务,无需复杂配置即可为企业及个人用户提供通信加密保护,甚至支持向 Outlook 等第三方客户端发送加密邮件。而 2 月启动的 “去密码化” 改革,通过二维码认证替代短信验证码,进一步强化了账户安全防线。行业分析师指出,停用老旧功能是为新安全体系铺路,谷歌正通过 “减法” 换取服务安全性与一致性的 “加法”。 针对受影响用户,谷歌已在帮助中心上线过渡指南:个人用户可在 2026 年 1 月前通过 “设置 - 账户 - 检查邮件其他账号” 路径切换至 IMAP 连接;依赖 Gmailify 垃圾拦截功能的用户,可迁移至谷歌 Workspace 的高级反垃圾邮件服务,或开启第三方邮箱自身的安全防护模块。谷歌强调,所有功能调整将分阶段推进,12 月起将向受影响用户推送专项提醒邮件。 目前,谷歌尚未披露两项功能的具体停用时间表及是否有恢复可能,但明确表示将持续通过 Gemini AI 升级 Gmail 核心体验,包括智能回复优化、搜索结果精准推送等功能已在逐步落地。此次调整或将影响全球数百万依赖多邮箱聚合管理的用户,如何平衡安全升级与用户习惯,成为谷歌后续服务运营的关键。
  • 有时候闲下来沟通几句说不定有新的灵感

    5 10
    5 文章
    10 评论
    小黑
    哈哈哈哈哈哈哈
  • 晓梦羊博客集专属板块

    1 1
    1 文章
    1 评论
    博客集
    凌晨一点的台灯下,刚给服务器续完费的鼠标还带着余温,后台跳出条新评论:“三年前你写的那篇建站教程,今天终于帮我搭好第一个博客了。” 窗外是短视频平台推送的 15 秒热点交替闪烁,而我盯着屏幕上那句留言,突然想给 2025 年还在敲键盘的我们,写一封迟到的情书。 还记得今年春天清理后台时的恍惚吗?翻到 2020 年的旧文,那时还在纠结 WordPress 主题要不要加夜间模式,如今已经能熟练用 AI 生成初稿,再逐字注入自己的语气 —— 就像给机器骨架贴上带温度的皮肤。有次朋友刷到我的博客,笑着说 “现在谁还看长文啊”,我没反驳,只是把后台显示的 “某篇 2023 年的技术文今日新增 5 次阅读” 截图存进了文件夹。这届读者很聪明,他们分得清哪些是 AI 拼凑的模板,哪些是熬了三个晚上啃透原理后写下的真心。 我们都曾遭遇过 “数字冷宫” 吧?花一周写的深度分析,阅读量不及短视频平台随手发的日常;调试了半天的 AR 交互插件,评论区只有两条问 “怎么打不开”。有位技术博主在社群里说,他曾盯着日均 700 的 IP 数发呆,直到某天收到字节的面试邀请,面试官说 “你博客里关于区块链共识机制的思考,比简历值钱多了”。原来那些无人问津的坚持,都在悄悄给我们的人生铺路。就像有人用博客记录育儿心得,三年后整理成电子书;有人靠分享服务器运维经验,结识了能远程调试代码的挚友,这些都是算法推荐给不了的礼物。 2025 年的博客早不是单打独斗的战场了。我见过有人在文章里嵌入可交互的代码块,读者能直接在线运行调试;也试过用 AI 插件做了个 “历史问答” 功能,老读者翻到旧文还能随时提问。上周和一位坚持 11 年的博主聊天,他说现在博客收入能覆盖生活开支了 —— 广告分成够交服务器费,知识付费的收入能支撑去实地考察写深度报道。那些曾经被嘲笑 “不赚钱” 的坚持,在商业化多元化的今天,终于长出了果实。 偶尔也会羡慕短视频博主的流量神话,但指尖划过自己博客的归档页时,又觉得这份 “慢” 格外珍贵。朋友圈的动态三天后就沉底,而我们的文字能在三年后还被搜索引擎打捞,成为陌生人的解题钥匙。有位旅行博主说,她的丝绸之路系列博文,三年积累了 50 万粉丝,有人因为她的文字真的踏上了那段旅程,这种连接比直播打赏更让人踏实。 此刻或许你正对着空白文档发愁,或许刚处理完服务器的突发故障,或许在纠结要不要尝试新的内容形式。但请记得,2025 年的数字世界里,我们这些守着一方自留地的人,正在做一件特别酷的事:用文字对抗信息碎片化,用原创坚守思考的深度,用长久的陪伴代替瞬时的狂欢。 敬我们这些 “不合时宜” 的坚持,敬每一篇被用心写下的文字,敬这个还愿意为深度思考驻足的时代。下一个深夜,当后台跳出新的互动提醒,我们依然会笑着点开 —— 因为这里不仅有我们的足迹,更有彼此的星光。
  • 提出问题,然后解决问题

    2 13
    2 文章
    13 评论
    十二
    @小黑 感谢
  • 给星态思提建议,反馈bug、问题,感谢您的支持,我们努力做好。

    0 0
    0 文章
    0 评论
    没有新文章

愿景


  • 让每一次思考都有价值,
    让每一次分享都有温度。

热门标签