IT瘾信息推荐

开源情报（OSINT, Open Source Intelligence）作为信息战、商业分析、网络安全调查、反欺诈等领域的 “利器”，越来越多地被情报分析师、记者、研究人员乃至普通网民所熟知。在这个资讯爆炸的时代，Telegram 成为了重要的信息源，尤其在俄乌战争、地下市场、泄露数据、政治动态等领域中，其重要性不容忽视。

那么， 如何高效、系统、深入地搜索 Telegram 中的公开情报信息？ 本文将以 5 个强大实用的 Telegram 搜索工具为核心，逐一解析它们的功能、使用方法、组合技巧以及实际应用场景，带你一步步成为 OSINT 搜索高手！

一、为什么要搜索 Telegram？

Telegram 是一个加密通讯平台，但其 “公开频道” 功能却是 OSINT 的宝库。许多组织、黑客、地下商人甚至政府消息源都使用 Telegram 发布内容。相比 Twitter、Facebook 等平台，Telegram 的 “封闭性” 与 “公开性” 共存，反而让它成为调查人员追踪目标、发现线索的首选平台之一。

二、核心搜索工具介绍

下面我们重点介绍五个可以用于 Telegram 搜索的工具，它们都是开源情报实战中不可多得的利器。

1. Lyzem Telegram Search

特点：

可搜索频道、群组、用户、BOT；
支持关键字、语言筛选；
提供频道分析数据（如订阅数、活跃度等）；
可用于发现目标活动范围或信息扩散路径。

使用教程：

打开网址： https://lyzem.com/
在搜索栏输入关键词（如 “Ukraine Drone”），可选择语言筛选；
点击搜索结果，可查看频道 / 群组简介和最近活跃情况；
可根据频道规模和内容活跃度判断其是否值得关注。

应用案例：
在追踪一个疑似诈骗组织活动时，输入关键词 “Crypto Scam”，找到了几个宣传投资骗局的频道。通过分析其发布时间与互动频率，进一步定位了其目标受众与资金流动路线。

2. Google Custom Telegram Search

特点：

利用 Google 自定义搜索引擎，索引 Telegram 的公开频道内容；
搜索结果更精准，支持高级搜索语法；
可批量查询关键词，搭配 Google Dork 使用效果更佳。

使用教程：

打开链接： https://cse.google.com/cse?&cx=006368593537057042503:efxu7xprihg#gsc.tab=0
输入关键词，如 bitcoin scam site:telegram.org；
查看 Google 返回的 Telegram 页面结果（通常是频道、贴文链接）；
结合搜索语法如 "telegram.org" AND "leak"，进一步精准定位。

使用技巧：

可结合 Google Dork，比如： "giveaway" site:t.me
可用于定位特定时间段发布的信息，搭配 Google 时间筛选功能。

3. TGStat.ru 国际版搜索

特点：

提供 Telegram 频道数据统计与分析；
可按照频道类别（如科技、新闻、黑客、成人等）筛选；
支持多语言界面，信息更新频繁；
提供最近帖子、订阅数、增长曲线等情报。

使用教程：

访问网站： https://tgstat.ru/en/search
输入关键字，可按语言、地区、类别筛选；
查看频道详情、帖子内容和数据图表；
还能查看该频道在其他社交平台的关联。

实际调查用途：
分析一个政治组织的消息扩散路径时，TGStat 提供的 “活跃用户时间分布” 和 “最常被提及的频道” 功能帮助我进一步拓展情报范围。

4. TelegramChannels.me

特点：

频道索引库，按类别细致分类；
可按国家、语言、活跃度排序；
每个频道有基础介绍、订阅链接和标签。

使用教程：

访问网站： https://telegramchannels.me/
浏览或搜索关键词；
可选定特定标签（如 “Leaks”, “Hack”, “Politics”）筛选结果；
点击频道标题，即可跳转至 Telegram 加入或查看内容。

使用建议：
适合初步探索某一主题下的 Telegram 生态图谱，比如想系统研究 “乌克兰战争” 的信息战格局，可逐类分析各阵营的频道分布。

5. Search.buzz.im

特点：

聚焦 Telegram 的内容搜索；
支持搜索公开频道和群组内容；
更新速度快，结果包含时间线和上下文；
UI 轻便直观，适合快速查找。

使用教程：

打开网址： https://search.buzz.im/
输入关键词（支持中英文）；
查看结果页面，包含简要预览内容；
可快速定位某条敏感信息的首次出现时间。

三、如何组合使用这些工具？

为了最大化搜索效果，可以将这些工具 串联起来使用，形成一个高效的情报采集链条：

情报采集链推荐流程：

Copy

   问题 -> 初筛关键词 -> TelegramChannels.me 初探生态 
     -> Lyzem 精准定位活跃频道 -> TGStat 分析数据
     -> Search.buzz.im 或 Google Custom Search 深度提取内容

实例：调查 “Telegram 上的金融诈骗团伙”

关键词确定： “crypto scam”、"investment fraud"
使用 TelegramChannels.me 搜频道 → 获取初始列表
用 Lyzem 查看活跃情况、加入日期、管理员信息
TGStat 分析是否存在订阅增长异动（操控痕迹）
Buzz.im 查找频道内是否有类似 “收款地址”、“钱包截图” 的内容
用 Google Custom Search 定向查找某个钱包地址是否在其他频道出现

四、使用技巧和注意事项

善用关键词组合：如 “泄露 + email”、“招聘 + 黑客” 等；
关注频道活跃曲线：TGStat 提供的数据可辨别是否是 “僵尸频道”；
频道间相互引用图谱：TGStat 或 Lyzem 能让你从一个点拓展到整个网络；
不要仅停留在表面：深挖频道历史内容，寻找可关联证据；
注意隐私与合规性：OSINT 虽是合法的公开情报，但也需遵守地区法律规定。

五、总结：Telegram 是 OSINT 的宝藏地

通过这五个工具的配合使用，我们可以快速、系统地在 Telegram 中构建一个强大的情报分析系统，无论你是追踪黑客活动、调查诈骗案件，还是监控政治动态，它们都将是你 OSINT 工具箱中必不可少的组成部分。

工具总览：

Lyzem Search： https://lyzem.com/
Google Custom Search： https://cse.google.com/cse?&cx=006368593537057042503:efxu7xprihg#gsc.tab=0
TGStat： https://tgstat.ru/en/search
TelegramChannels.me： https://telegramchannels.me/
Buzz.im Search： https://search.buzz.im/

END

大数据时代下，如何识别垃圾信息？

Tue, 16 Aug 2022 14:14:24 CST

编辑导语：大数据时代之下，信息繁杂多样，其中也充斥着大量的假话和谬论。怎么在纷繁复杂的信息里面，去伪存真，需要我们有一定的思辨能力，去识别信息中的垃圾信息。而如何识别辨别这些垃圾信息呢？本篇文章分析了如何识别垃圾信息的方法，感兴趣的话一起来看看吧。

短视频、短信息时代蒸蒸日上，改变了公众话语的内容和意义，政治、宗教、教育、体育、商业和任何其他公共领域的内容，都日渐以“短娱乐”的方式出现，并成为一种文化习惯。

但是这些容易传播的短视频、短信息，大量充斥着假话和谬论。

基思·斯坦诺维奇说，伪科学的传播所造成的代价是巨大的。怎么在纷繁复杂的信息里面，去伪存真，帮助自己解读判断，需要我们有一定的思辨能力，去识别信息中的垃圾信息。

一、如何识别垃圾信息？

1. 大话、空话；让人不知所云

在表达中使用一堆假大空的词汇，每个词你都认识，组合在一起也仿佛说得都对，但是就是不知道对方在说什么。比如各种黑话指南：

2016年：资本寒冬、护城河、上半场、下半场、brief、知识付费、赛道、黑科技、网红、闭环。
2017年：赋能、边界、共享经济、消费升级、新物种、互联网金融、ICO、区块链。
2018-2019 年：打法、优化、下沉、社交电商、壁垒、流量池、组合拳、心智。
2020-至今：抓手、Web 3，去中心化、底层逻辑、第一曲线、第二曲线。

并不是说只要有这些词汇，就是垃圾信息。而是表达者通过一顿组合，让你不知道所云，只有空话的，肯定是垃圾信息。比如：

这次 Campaign 我们要以价格为抓手，横向打通品类覆盖，还要提高内容可复制性，注重投放颗粒度，覆盖消费升级到下沉市场的全域流量，发力打出一套组合拳。

看完之后，一脸问号，他在说啥？

向飙说：“社会生活里有很多问题都是老问题，一定要把老问题吃透。不要制造新的词汇，没有太大的意思”。

2. 缺失的信息

之前文章《如何正确读数和更优决策》，讲了一个关于缺失数据做决策的故事。赛车队成员需要决定是否要参与一场重要的比赛。依据之前的经验，24 场比赛中有 7 场汽车引擎出现故障，故障情况和天气温度之间的关系如下图：

图片来源于《成长边界》

团队里面大部分人的判断都是要参赛。但是当我们把缺失的比赛数据补齐时，我们看到：

图片来源于《成长边界》

40华氏度引擎出问题的概率很高，参赛的结果可想而知。赛车队故事背后是 NASA 真实的案例。1986 年，在一次火箭发射事件中，NASA 的高层基于部分数据，对于密封火箭助推器一个连接处的 O 型圈失效可能性做出了判断。最终结果是，剧烈燃烧的气体直接从连接处冲向外部，“挑战者号”在升空 73 秒后就爆炸了，7 位宇航员全部丧生。

当有人和你阐明数据和观点的时候，你可以思考以下几个问题：

谁在告诉我这些
他们是如何知道的
这些信息里面还有什么，还有哪些信息没有表露出

3. 错把关联当因果

还有一类经常被大家搞错的是，误把关联关系当作因果关系。

多年前，台湾地区有一个研究表明，家用电器的数量和避孕工具的使用最相关。但是你应该不会有这样的想法，在高中发放免费的烤箱以解决青年早孕的问题。因为这两个变量存在相关，但是没有因果关系。

比如你发现汽车儿童座椅销量变高，同时婴儿出生数量也在变高，是一个正相关的关系。但是不能说，因为儿童座椅销量变高了，所以导致婴儿出生率变高。这是逻辑是谬论。

导致两个变量之间产生误导性关联的第三变量，有时候很容易看出来。比如，冰淇淋卖得越多，溺水就越多。是因为吃冰淇淋的人很多，游泳的人也很多，所以溺水的人才很多。

我们在研究一个现象的时候，会带着自己的预设偏见理解为，两个相关因素是因果关系。而相关关系之所以产生，可能是因为这两个变量都与某个甚至尚未被测量的第三变量相关。

读数据的时候，当我们看到相关关系，需要继续提问或者反思，背后的原因是什么，是否还有其他可能性。

4. 小心平均值和中位数

平均数代表一个样本的平均水平。但是当你在查看平均值的时候要留意，样本里面是否有极值（极大值，极小值这些 outliers），如果有的话，平均值就会不准。此外，如果你的样本小，也容易产生更多极端的值。这个时候用中位数更合适。如下图：

图片来源于 B 站公开课程

5. 正确理解 p 值

什么是 p 值？

我们来说一个故事。假设你是一个律师，现在法官要审判一起杀人案件，而你的辩护人被指认谋杀。但是案发时，你当事人在蛋糕房里面做蛋糕，并不在案发现场。现在你要为他辩护。

庭上法官拿出 DNA 检测报告表明，案发现场凶器上的 DNA 和你当事人 DNA 完全吻合。所以你的当事人才被指认。

作为律师你说，“等一等，法官你确定 DNA 匹配不是巧合？”

法官说，“当然，DNA 匹配概率是百万分之一。你的当事人是凶手无疑。”

你说，“别急，我们来画一个图。百万分之一的可能性表达的是所有人群里面，错误识别的可能性。但是我们这里应该要看的是，识别出来的结果里面，被误识别的可能性。”

图片来源于 B 站公开课程

“虽然对于整体样本来说，检错概率很低，为百万分之一。但是在判断为凶手的结果里，总共 5 个人，只有 1 个是真正的凶手，其他 4 个都是误判，只有 20% 的正确率。没有办法判断我当事人就是凶手。”

这则小故事告诉你不能绝对相信 p 值。因为 p 值不是用来告诉你假设的正确性的。而是用来告诉你，在整个群体中检测错误的可能性有多大。

所以对于一个很低的 p 值，不要认为这事就肯定成立了。

6. 误导性坐标轴（misleading axes ）

数据可视化可以降低看数据的难度，但是在数据以图表的方式呈现出来之后，我们也需要去关注一些细节。因为图表会给出一些诱导性的表达方式，影响我们判断。比如误导性坐标轴（misleading axes ）。

以下图为例，作者给你看的图是这样的，我们会快速认为，yes 和 no 的比例是 5/5 开。但是细看我们会发现，这两个分类左边的 y 轴并不一样，根本不是 5/5 开的关系。

图片来源于 B 站公开课程

7. 操作箱尺寸

图表也可以操控每个箱子的尺寸大小来表达他想要的意思。比如下文是华尔街一篇臭名昭著的报道。这张图乍一看中间部分的 y 值最大。

图片来源于 B 站公开课程

但是当我们放大横坐标的时候仔细一看，会发现，横坐标根本不是等分的。从最开始的每 5k 一个间隔，到后面 5百万一个单位。

图片来源于 B 站公开课程

8. 过度装饰

过度装饰的图被称作 data visulization ducks。ducks 原意是用在建筑领域指过度装饰的建筑。图表也是如此，好的图表不要过度装饰，过度装饰反而会失去了他本来想要表达的内容。因为 ducks 会阻碍信息的交流。

（假新闻 & 过度装饰）图片来源于 B 站公开课程

（画个人形，读数反而变得很困难）图片来源于 B 站公开课程

（视觉注意力都被大汉堡和苏打水抢走了）图片来源于 B 站公开课程

（用嘴型来表达家庭的财务安全度）图片来源于 B 站公开课程

（非要用栅栏表达房屋价格，让人看不懂）图片来源于 B 站公开课程

（过度装饰 & 误导性坐标轴）图片来源于 B 站公开课程

9. 科学的可复制和可重复性

‍你看到的信息能否被复制和重复，这也是结论是否科学的一个重要判断因素。要将一个研究发现认定为确凿的科学事实，它的可重复性至关重要。因为科学理论的一个重要定义就是可证伪性。

可证伪性标准声明，一个理论要有用，对其所做的预测必须是具体的。它在告诉我们哪些事情会发生的同时，必须指出哪些事情不会发生。如果不会发生的事情确实发生了，我们就得到了一个明确的信号，这个理论有问题。

越具体的预测在被证实后，给我们的触动越大。预测越具体，越精确，有可能证伪它的观察现象就越多。

只有当一个理论并不试图预知一切，而是做出具体的预测，提前告诉我们世界上会发生什么具体的事情时，该理论才会进步。

所以伪科学/信息的另外一个特征就是不可证伪。不管怎么解释它，都对的。

这些不可证伪理论有着巨大心理吸引力，其奥秘在于它们解释一切的能力。预先知道无论发生什么，你都能理解它，不仅给你一种掌握知识的感觉，而且更重要的是，给你应对这个世界所需要的情绪上的安全感。

但是这种安全感是以知识发展的停滞为代价的。比如我们常常沉迷的占星、星座解释、通灵术等。

二、最后

Steven Pink 说过：活着好过死亡，健康好过疾病，富足好过匮乏，自由好过胁迫，幸福好过苦难，知识好过迷信和无知。

在这个不确定性极高的后疫情时代，多多提高自己对信息的辨别能力，更好的生活，从驳斥垃圾信息开始。

参考资料：

《大数据时代，如何识别 bullshit》，https://www.bilibili.com/video/BV13E411s74P?spm_id_from=333.337.search-card.all.click

《The social dilemma》2020 on Youtube, https://www.youtube.com/watch?v=rvg0eY_Ls4Y

《成长边界》

《这就是心理学》

作者：圈圈，微信公众号：lovepm

本文由 @圈圈授权发布于运营派。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

信息茧房是如何一点点织成的？|界面新闻 · 文化

Wed, 11 May 2022 11:28:16 CST

编者按：因为越来越多的固定信息投喂，人们在目前的互联网环境中成为一个个孤岛，“信息茧房”越筑越坚固。如何突破信息茧房？本文的视角是回归人类认知。作者考察人类认知遵从“节俭性原则”，即在信息处理上用最小的能量消耗，获取最多的生存便利。在大数据环境之下，个体认知的节俭性特点不断被放大，从而形成信息茧房。而想要实现资源共享和互利，削弱壁垒，也同样可以利用认知效应：类似粉圈的“出圈”现象，新旧粉丝群可以借助认知效应实现融合。

《人类认知与信息茧房》

文 | 徐英瑾（《读书》2021年6期新刊）

二十世纪九十年代互联网经济刚刚出现的时候，媒体对于互联网的发展是抱有某种玫瑰色的幻想的：互联网会将整个世界变成一整片信息平地。这样一来，知识密集地域与知识稀疏地域之间的各种差别也就变得不重要了，优质的信息能够自由地流动到世界的任何一个角落。但随着时间的推移，真实的互联网世界却带来了所谓的“信息茧房”（information cocoons）与“回声室效应”（echo chamber）——互联网上海量的信息喂入，反而导致了大量的互联网用户成了如同困在蚕茧里的“蚕”，只能看到自己眼前的一亩三分地；或者变成了困在密室里的孤独的说话人，只能听到自己的回音。由此，具有不同偏好的不同信息获取人群，反而在目前的互联网环境中变成了老死不相往来的信息孤岛，加剧了世界上本就存在的信息壁垒。

网络大数据（来源：amz520.com）

为何这种怪异的现象会发生？我认为是互联网技术以及背后的大数据技术，充分利用了人类认知架构的某些特点——特别是那些用以加速信息处理进程的“捷思法”（heuristics，即体现“节俭性”原则的心理诀窍）——由此使得具有相同内容属性的信息与特定的人群之间的捆绑效应变得更为明显。而在这套捆绑机制背后起效的，乃是资本运作的内在逻辑。

01

毫无疑问，无论支撑目前的互联网运作的数据技术有多么前沿，互联网的广大用户与相关平台的运营者和控制者，依然都还是人类。换言之，基于人类的生物性本质，目前的互联网运作实际上是具有明显的“半生物性”的。然而，耐人寻味的是，对于这一如此明显的事实，主流的互联网叙事却往往视而不见，并更习惯于将一部本来具有一半生物性色彩的互联网进化史，简单化为一部纯粹的“硅基”的技术进化史。而现在我们的任务，就是要将这张被过分简化的图景予以复原。

从演化心理学的角度看，与其他动物的大脑一样，人类的生物学大脑，其实也可以被视为某种抽象的生物计算机——其目的是从复杂的外部环境中提取有用的信息，以便提高生物体自身的繁殖适度性。然而，这种“计算机”的真正运作程序，却高度体现了“节俭性”的原则，也就是用最小的信息处理能量损耗，以产出那些最能提高繁殖适度性的行为。以下就是一些充分体现这些“节俭性”原则的著名认知效应——其中，每一个效应都会为生物体带来生存上的便利，但是也都会带来认知上的偏差。一是锚定效应。该效应说的是，认知主体最先获得的印象，会像船锚一样在其记忆中获取更稳固的位置，并使得后来的关于同一类事物的印象难以发挥像原初印象一样的认知作用。这一效应显然能够大大节省认知主体的信息处理成本。譬如，假设一个主体要判断乌鸦是什么颜色，他大可不必花费精力审视天下乌鸦，而只要审视他最先看到的那几只乌鸦就可以了。但因为该效应，认知主体容易犯下“仓促概括”的错误。二是贴标签效应。即认知主体会将他所看到的各类事物贴上标签，以方便其对于万事万物的分类。这样做的好处，显然减少了需要被信息主体处理的信息模块的数量，减少了主体的管理成本，而其缺点也是明显的：如果主体按照过于简化的（或者错误的）标签来对事物分类的话，那么主体就会产生对于世界的错误的认知图景，并由此在现实世界中碰壁。三是“易思者易赢”效应。该效应说的是：主体在判断某事物的某个属性是否明显的时候（譬如演艺圈的明星是否离婚率高的时候），主要的根据是相关属性是否容易在脑海中被唤起，而不是根据该属性在真实世界中出现的频率。考虑到调取“事物属性的真实出现频率”所需要付出的大量认知负荷，该效应的存在，显然大大减少了主体的认知负担。但是，在某些情况下，主体也会因为这个效应的存在，而被偶然想起的事物性质牵住了鼻子，由此失去了对于事物的不同性质之间的真实配比的把握。四是极端预期效应。即在主体所面临的某个与其利益颇有关联的事态还不是很明朗的时候，主体会匆忙对其最终走向做出具有“好”“坏”两种极化色彩的预期。这种做法的好处是，能够让主体在事情结局最终出现之前，先行准备针对相关结局的应对方式，缩短“信息处理”与“行动”之间的链条，由此减少信息处理的成本；而其缺点是：它会使得主体因为轻率下赌注而失去对于巨变的形势的应对能力。五是花车效应。该效应说的是，主体在无法根据自己的认知能力判断相关信息的真实性时，往往会根据社会主流对于该问题的判断方式来下结论，就像在参加花车游行时随意跳上一辆貌似最花哨的花车一样。这样做的好处是，认知主体可以通过向社会主流或者相关权威“借脑”来缩减信息处理成本；坏处则是，认知主体很可能被一些虚假权威所误导，陷入认知陷阱。

人际网（来源：36kr.com）

需要注意的是，虽然上面提到的每一个效应都会给认知主体的适应性带来利与弊，但在使得人类的认知架构得以被演化出来的漫长的采集—狩猎时代，它们所带来的好处是压过相关的坏处的。因为原始的采集—狩猎的环境是天然形成的，并没有明显的人为设计的痕迹。并不会导致严重的归纳不当问题。而且原始的采集—狩猎时代的环境要素相对简单，原始人的认知架构只要去关注那些与其生物学需求高度相关的环境因子（如食物、配偶、天敌、天灾等等）就可以了，无须考虑那些具有抽象性的概念（如货币、资本等等）。这也就使得“贴标签效应”引发错误的概率减少。同时，在此类环境中，与“极端预期效应”相互捆绑的事件种类本来就高度局限在基本物质需要的范围内。与之相较，抽象的意识形态斗争而导致的社会极化现象，在当时反而是不普遍的。当时，中介性的信息传播环节也非常不发达，一个人所能想起来的某事物承载某性质的频率，往往就是他所看到的该事物承载该性质的客观频率，而不是在某种第三方媒介的刻意引导下，他所看到的该事物承载该性质的频率。这种境况就使得“易思者易赢效应”的负面影响不至于太大。同理，也正是因为社会中介性媒介的不发达，任何一个认知主体都能轻易地通过对于信息传播链条的追溯来找到信息源，并要求作为信息源的信息发送方对信息本身的质量承担社会责任。这也在相当程度上遏制了“花车效应”的负面意蕴。

但在现代信息社会中，采集—狩猎时代的环境参数，已经被全面地修改了。这也使得那些在原始环境中具有适应性的心智特征，变得不再具有适应性。首先，我们所处的环境，早已是被高度人工化的环境。譬如，你在地铁里看到的广告不是天然形成的，而是人为设计的；你在马路上看到的姑娘之所以都穿上某种颜色的衣服，也不是因为这种颜色能够提高她们在特定环境中的生物适应性，而仅仅是因为这就是今年的“流行色”（对于“流行色”的设定机制，本身就是现代消费主义话语体系的一部分）。在网络的虚拟世界中，上述这种“人工性”已经被夸张到了无以复加的地步。与物理人工物的构建相比，数码虚拟物的构建所需要付出的成本更低，因此，对于这些虚拟物的设置所遭到的来自物理世界的硬性制约也就越少。这也就会使得“锚定效应”更容易导致认知偏见，因为主体在网络上所接收到的关于某事物的某初始印象，完全有可能是人为安排的结果。其次，现代人处于复杂的软硬件环境，要对应这种复杂性，人类就要开发出非常复杂的抽象概念来操作相关的社会机器。但由于人类的实际认知能力的基本要素（如脑容量、工作记忆容量等）并没有等比例地被复杂化，这就使得单个的现代人所实际能够掌握的概念图谱与复杂环境之间的落差被急剧地拉大了。这也就使得“贴标签效应”的负面意蕴更有机会在现代社会中得到展现。再次，现代社会的信息中介性环节非常发达，使得某个人所了解的关于遥远国度的新闻，就只能局限在媒体所展现给他的那个信息界面之中。在信息源本身被污染的前提下，上述局面就会为“花车效应”的全面泛滥大开方便之门。同样，“易思者易赢效应”的负面意蕴也会被随之扩大，因为信息主体所更容易想起的事物的属性，很可能不是事物的相关属性出现的真正频率，而是相关属性在媒体中出现的频率。最后，现代社会的物质生活高度发达，大量主体能有更多的闲暇时间从事精神活动，因此，原始心智中的“极端预期效应”所适用的事件类型范围也被急剧扩大，即从波普尔所说的“第一世界”（物理世界）与“第二世界”（心理世界）迅速拓展到了“第三世界”（精神虚拟物世界）。换言之，导致极化效应的诱因性事件的数量被迅速扩大，人群之间发生撕裂的可能性也大大增加了。而在数码时代，由于制造虚假信息以扰乱“第三世界”之信息场的成本变得越来越小，更多的认知主体就更容易在前述“花车效应”“锚定效应”等心理机制的作用下而被虚假的立场所蛊惑，由此也拉大了与别人的立场差距。

色彩权威 PANTONE（彩通）每年都会公布年度色彩（来源：Adobe Stock）

上述所有这些环境要素的变化，都会在互联网时代催生信息茧房。其背后的成因机制可以被分解为如下的步骤：第一步：不同的虚拟信息生产主体，会根据各自不同的利益，产生不同的价值判断命题，譬如对于某商品具有的某正面属性的积极判断。因此，虚拟世界便成为这些海量的价值评判命题（以及与之配套的人工证据体）彼此角逐的战场。第二步：对于单个的信息接收主体来说，其认知架构的“节俭性”本质，驱使其只能在这些海量的信息中随机挑选出少量的判断作为其信念体系的一部分，以免其认知架构出现“信息过载”的问题。而在网络世界中，某人采纳某个信念的重要指标，便是用浏览记录来表达自身的，即他点击并浏览了表达该信念的虚拟内容界面（文章、音频或者视频等等）。第三步：大数据技术驱动下的内容推荐技术，会根据个体在虚拟世界中的信息轨迹，向其推荐类似的信息，以便利用锚定效应来迅速形成相关主体的信息检索习惯，以方便日后的广告推送业务的展开。第四步：这样，个体之间因为某些偶然性因素而被形成的起始性信念体系之间的差异，就会通过大数据环境与个体认知架构之间的合谋而被不断扩大，由此形成信息茧房。

面对这样的境遇，该如何破茧呢？

02

在讨论破茧之法之前，首先要确定哪些事项是我们无法改变的。首先需要肯定的是，人类的认知架构的节俭性是某种生物学常项，无论出于生命伦理还是技术可行性方面的考虑，我们都不能通过系统化地改造大脑来改善认知处境。而需要改变的，显然就只能是那些使得人类认知架构的缺陷得到全面放大的相关数据技术。具体而言，我们似乎可以改变目前方兴未艾的内容推荐技术的深层运作逻辑，即从“强化用户既有购买习惯”的轨道转到“拓展用户的兴趣范围、增加其视野”这一新轨道上来。

但这一转轨是否可能发生呢？这一问题本身又可以被拆解为两个子问题：第一，使得上述转轨得以发生的技术革命是否可能发生？第二，使得上述技术革命得以发生的社会资源（如资金、时间与人力的投入）是否能够到位？笔者对第一个问题，持谨慎乐观的态度。毋庸讳言，在贝叶斯统计技术与深度学习技术的支持下，当下主流的网络内容推荐技术往往是根据大多数人的既有网络轨迹特征来预测特定用户的相关网络行为的，而这一做法，也往往会使得个体成为既定“用户画像”的无个性的注脚。尽管如此，反向的技术研发，也并非不可能。举例来说，技术研发者当然可以向用户推送与其浏览习惯相反的内容产品，譬如给美国民主党的选民推送体现共和党执政理念的内容视频。然而，为何在现实世界中，很少有人这么做呢？这就牵涉到支撑内容推荐技术得以被发展与运用的资本环境问题。数码技术的开发与运用当然是需要大量资本支撑的，而资本的投入是需要回报的。以YouTube为例：在该平台上，资本的回报方式往往与插入内容视频的广告观看率有关，而这一数据又与该视频本身被点击的次数有关。很显然，要使得具有任何一种特定政治倾向的视频被点击的次数最大化，其不二法门就是将其推荐给其他可能持有该倾向的用户，而不是将其推荐给抵触该倾向的用户。而内容的制作者在有了相对固定的用户群后，也会根据他们的口味固化产品的内容倾向，以保证自己的经济收益。换言之，如果有人要开发出一种旨在拓展用户视野、弱化信息茧房效应的新内容推荐技术的话，那么，该技术在研发动机的层面上就会受到资本力量的扼杀与打击，或至少是漠视。

协同过滤算法图示：左边是基于用户的算法，右边是基于物品的算法（来源：36kr.com）

从上面的分析来看，资本的运作逻辑与人类原始心智运作方式之间已经出现了高度的耦合，破茧之路似乎已经被封闭。但是否有别的办法能够改善这个情况呢？

办法是有的。其基本思路就是顶级资源的掌控者能够理解这一点：要提高内容的被关注度，不一定要靠强化茧房的壁垒——有时候削弱这一壁垒反而是对资本有好处的。在中世纪的欧洲，群雄割据，各占一方，没有一个伯爵或者公爵可以直接调动别的伯爵或者公爵领地里的人力资源。在这种情况下，整个欧洲就是一个被高度网格化的“资源茧房”，也就是说，每一个封建领主都只能获得其领地内的资源，而无法染指别人家的资源。

尽管如此，诸侯之间的吞并依然不断发生，而且，诸侯之间基于自愿的资源整合，在历史上也是经常发生的。这种整合主要依赖三种方式：诸侯之间的直接联姻、宗教权力（特别是罗马教廷的权力）黏合下的结盟、“周天子”式的象征性高端权力（如德意志神圣罗马帝国皇帝）黏合下的结盟。但无论以何种方式完成的资源整合，其目的都是解决各个“资源茧房”彼此孤立后所导致的资源分散问题，以盘活某些闲置的资源，最终实现资源运用的最大效益。

欧洲中世纪城市图（来源：pin.it）

从某种意义上说，今天互联网世界中的“信息茧房”，就可以被视为中世纪的“资源茧房”的虚拟化版本；而按照某些兴趣偏好所组织的某些粉丝群，则可类比于当年中世纪的一个领主辖地内所具有的所有人力资源。所以，就像中世纪的诸侯们完全有可能在某些共同利益的支配下弱化“资源茧房”之间的壁垒一样，今天互联网时代的资本掌控者也完全可能在某些共通利益的考量下去弱化“信息茧房”之间的壁垒，以图实现某种长远利益。一种特别能够为这种可能性提供注解的，便是在时下方兴未艾的“出圈”现象。简言之，一个在某个圈子里积累了大量粉丝数的具有重大IP价值的互联网标签人物，也可以在另外一个圈子里取得重大的成功，并由此使得新粉丝群与旧粉丝群产生融合。而这种融合之所以发生，也恰恰是因为“出圈”现象本身非常神奇地利用了本来造成“信息茧房”效应的受众心理机制，达到了破坏茧房壁垒的效果。其具体运作过程如下：偶像本身所积累的人气，使得偶像的举止本身就成为一辆巨型花车，吸引了大量的网络关注度；偶像的“跨圈”或者“出圈”行为，使得偶像所具有的标签也多样化，由此在客观上丰富了粉丝们的标签库，弱化了“贴标签效应”的负面效应（即降低认知主体对于世界的复杂度的估计）；偶像的跨圈行为一旦成为思维定式，受众的锚定效应就会被激活，由此对别的偶像的跨圈活动构成期待，形成一种无形的压力，以促成偶像界的优胜劣汰；一旦跨圈行为形成了某种声势，那么，极化思维效应的运作方式也会发生迁移——本来是一个圈与另外一个圈之间各自粉丝圈的彼此极化与彼此鄙视，而现在则变成了能够跨圈的偶像的粉丝群对于无法跨圈的偶像的粉丝群的鄙视。

手机里的信息茧房（来源：cfnews.com.cn）

很显然，这种由IP自身的自主漂移所导致的受众心理的变化，并不是以一种强迫的方式发生的，因此要比用软件强行向用户推荐“圈外”的信息来得更为奇妙。不过，要实现这种以产生茧房的心理机制自身去破坏茧房自身的奇妙效应，还要满足两个条件：一是顶级资源的掌控者，需要从战略角度意识到打破茧房所能产生的长远经济利益。从排列组合的角度看，如果一家公司所掌握的三个IP资源原本各自只具有A、B、C三种特质的流量的话，那么，这些特质的互相排列组合方式将产生大量的新的可能的IP呈现方式，由此导致内容资源的全面丰富化。二是偶像需要提高自身的素质，以便为负载更多的IP属性提供相关的技能与知识储备。在上述过程中，政府力量则可以以一种“润物细无声”的方式促进那些弱势文化标签（如传统戏曲、传统工艺）与强势文化标签（如二次元文化）进行联合的文创方案，使得一些弱势文化标签搭上“大花车”的顺风车。

来源：读书杂志

原标题：《读书》首发徐英瑾：人类认知与信息茧房

上海疫情，有哪些能帮到大家、值得传播扩散的抗疫攻略或者实用信息？

Sat, 09 Apr 2022 00:00:00 CST

最近被问的最多的就是「XX发芽了能不能吃」、「XX过期了能不能吃」和「还有什么食物能吃」……

下面是我的朋友和读者投稿的一些问题汇总。 若大家还有自己的问题，欢迎留言，我会尽一切努力解答。

活下来最重要。

食物储存方向

土豆发芽/发绿了，还能不能吃？

对于我这样一个食品安全答主来说，正确答案当然是 「最好不要吃，全扔掉」。但上海现在在特殊时期。所以 如果你一定要吃，我有以下建议：

在土豆的芽还非常小，土豆本身也比较硬的情况下，把芽和芽周围的组织彻底去掉，剩下部位放水里泡一段时间再食用，有助于减少龙葵碱中毒的风险。
绿色部分面积不大的话，彻底去除绿色部分以后再食用，也能减少风险。
如果 土豆芽/绿色部分面积已经比较大，或者土豆 本身发软，那 食用风险很高！千万不要吃！全身发绿的土豆即使没有发芽，也不要吃！现在这种情况，吃出问题了去医院也比较难！

发芽/发绿土豆中所含的龙葵碱是一种神经毒素，摄入后会出现腹泻、呕吐等症状，严重的可能有生命危险。绿色本身是叶绿素造成的，但叶绿素合成旺盛的组织中往往龙葵碱含量也高。

如何阻止土豆发芽/变绿？

土豆储存时应尽量在 阴凉干燥处，避免光照。光照会促进土豆变绿。可以用纸袋把土豆包住，使其处于黑暗条件下，这样可以延长土豆储存时间。

有一些研究发现 乙烯有抑制土豆发芽的效果。所以也可以尝试将土豆跟苹果、香蕉等容易产生乙烯的水果放在一起。但这样做可能会加速水果的发霉或腐烂，需要斟酌一下。

关于更多蔬菜储存小技巧，可以看我之前的一篇文章：

参考文献：Dai H, Fu M, Yang X, et al. Ethylene inhibited sprouting of potato tubers by influencing the carbohydrate metabolism pathway[J]. Journal of food science and technology, 2016, 53(8): 3166-3174.

葱/蒜/洋葱发芽了呢？

能吃。只是营养价值可能会损失一些。网上也有教自己养蒜苗的文章。只要没有腐烂、变质，一般不会有太大风险。

其他食物发芽了呢？

大部分基本都能吃。花生、红薯等食物如果发芽了，要注意是否霉变。如果没有发霉，那就可以正常食用。豆类发芽了反而营养价值会提升。

有哪些食物需要彻底煮熟，煮透后才可以吃?

1. 四季豆（又称为菜豆、芸豆、刀豆，有些地方叫豆角）和扁豆中含有皂素，皂素对消化道粘膜有很强刺激性，摄入过多就会导致中毒。这些豆类应彻底煮熟食用。

将四季豆或者扁豆煮至软烂，失去生绿色，闻起来没有豆腥味，吃起来没有生硬的感觉，此时毒素就已经分解，四季豆、扁豆就可以安全食用了。

2. 新鲜的黄花菜中含有毒素秋水仙碱，烹饪鲜黄花菜时，必须非常小心。建议先将鲜黄花菜在开水中焯烫数分钟，然后用清水充分浸泡持续 2 小时，取出后冲洗干净，再进行烹饪。这样一来秋水仙碱可以最大限度地溶解在水中。吃起来风险也会比较小。

干制的黄花菜相对比较安全，因为干制过程中大部分秋水仙碱都会被破坏。但是谨慎起见还是建议复水后的烹饪时间尽可能长一点（比如10分钟以上）。

3. 新鲜银耳、泡发过程中的银耳和木耳容易受「椰毒假单胞菌」污染，这种细菌会产生米酵菌酸和毒黄素这两种毒素，引起中毒症状。

尽量不要吃新鲜银耳。如果是泡发的银耳和木耳，切记泡发过程千万不能太久，几个小时就够了，不需要泡发一整天甚至更多天。有条件可以选择在冰箱中泡发。泡发后立即烹饪食用，不要在生湿的状态存放太久。

长斑点的白菜和卷心菜能吃吗？

白菜和卷心菜的斑点需要区分是霉斑还是自带的「胡椒斑」。有霉斑是肯定不能吃了。「胡椒斑」像是胡椒粉撒上去那种感觉，是正常生理现象，一般是可以吃的。

" width="640">胡椒斑是长这样的，注意跟霉斑辨别！

发黄的西兰花、小青菜能吃么？

只要没有腐烂，霉变，就可以吃。

小鸡腿是放在冷冻还是冷藏？

鸡腿冷藏只能保存两天，想更长时间保存一定要密封以后放冷冻！

过期食品能不能吃方向

注意：这些问答都是建立在疫情当下物资不足，没办法的情况下应急。如果有条件的话，我不建议大家吃过期食品。

过期的牛奶可以喝吗？

短保质期牛奶（巴氏杀菌奶、高温杀菌奶）一般保质期在一个月内，需冷藏保存，微生物没有彻底消灭。一旦过期，食品安全风险会增大很多， 对于这些牛奶建议一旦过期还是不要喝了（即使只过期几天，风险也会增大很多）。

长保质期牛奶（超高温灭菌奶）一般保质期在半年以上，由于已经杀灭所有细菌，内部处于「商业无菌」状态，因此「过保质期」主要是口感下降，过期不长的话，一般不用过于担心食品安全问题。

牛奶在开封后，只能保存较短时间。有时候即使没有过期，但你已经能闻到味道不对了。这种情况下，也请扔掉，不要冒险。 不仅是牛奶，任何饮品在开封后都要尽快喝掉，不能久放。

过期几个月的饼干/点心可以吃吗？

常温保存的饼干、点心类食物，水分含量通常不高，但油脂含量通常比较高。所以影响保质期的最关键因素一般是「油脂氧化酸败」而不是微生物繁殖。 除了饼干、点心，还有坚果、泡面、各种油炸零食等等都是同样道理。

因此，如果过期时间不长（不超过1.5倍保质期），只需要闻一下这个食物的味道。如果味道不对了，那就不要吃。 如果味道正常，说明没有明显氧化。那还是可以吃的。

有些糕点是冷藏保存，保质期也只有很短时间的。这种短保质期糕点一般水含量高，微生物容易繁殖。一旦过期就建议不要吃了。

总之， 冷藏的「短保质期食物」过保质期不建议吃；常温保存的「长保质期食物」过保质期时间不长、没有异味的话就还能凑合吃。

米面类过期好几年还能吃吗？

米如果真空保存，没有 生虫发霉问题的话，问题不大。干面制品（面粉、干的挂面、干的意大利面等）也是同样道理。但因为氧化，口感可能会有较大下降。

如果一旦有发霉，或者有霉味，那千万不要吃！！！谨防黄曲霉素中毒。

当然，即食米饭/湿面这些短保质期产品不在我们说的范围内。

过期的酱油、酱料还能用吗？

如果没有开封，且过期不太久，那问题不会很大。注意酱料如果出现胀瓶、胀包、异味之类的问题，即使没过保质期也不要吃了。

很多酱料、酱油、调味品在开封后必须放置于冷藏条件下保存。标签上如果写了这一行，你没有放冷藏条件，那也可能引起腐坏变质。这个一定要小心。

过期太久的酱料依然存在风险，最好不要吃了。

过期的黑巧克力能吃吗？

普通的巧克力在保质期内主要是起霜（就是出现白色斑点、条纹等）。过期不太久的话，由于起霜和氧化，巧克力口感会有很大下降，但吃起来一般不至于有食品安全问题。

生巧克力、松露巧克力保质期很短，由于水分含量高，过期了就有食品安全隐患。这些产品过期了最好不要吃了。

过期六个月的火腿肠能吃吗？

火腿肠已经经过高温处理，并且一般都会添加防腐剂，抑制细菌繁殖，因此它的变质主要表现在氧化口感下降。

如果火腿肠包装没有破损，过保质期不太长，口味也没啥变化的话，那还是能吃的。但是六个月我认为是有些长了（大部分火腿肠保质期也就在6~9个月左右），因此建议尽量别吃了。

过期的月饼可以吃吗？

月饼要注意是否发霉。如果有发霉，或者味道不对的情况，就尽量不要吃了。过期不太久且味道正常，那还可以吃。

过期的冷冻食品能吃吗？

如果储存过程中一直严格保持冷冻的话，过期一段时间的冷冻食品，食品安全不会有太大问题。

但是，冷冻期间食物也会缓慢氧化，因此过期冷冻食品的口感会变差。

过期两个月的，日东红茶奶茶粉可以喝嘛？没有开封，保质期是一年的

味道没有改变的话，问题不大。

那么过期的咖啡呢隔离了只能喝过期咖啡了不知道会怎么样

过期成品咖啡豆、干粉、挂耳、胶囊，速溶咖啡、罐装或者瓶装的液体咖啡，如果过期时间不长，没有发霉变质的话，问题不大。需要警惕的是短保的冷萃咖啡液。这东西微生物是容易繁殖的，过期了就得扔了。

过期的维生素可以吃吗，复合型的，一袋好多颗的那种

营养补充剂的保质期通常会通过有效成分的残留量来定义。保存过程中，维生素本身一直持续损失，损失到一定程度就到保质期终点。因此，过期维生素吃了效果会大打折扣。

坚果、葡萄干以及蜜饯等过期将近半年还能吃吗？保质期是一年，闻起来没坏

注意发霉和氧化。如果没有发霉，味道也正常，还能凑合吃。出现任何味道改变就不要吃了！

请问过期的食用油呢？花生油，橄榄油，香油等等。家里还有三年前的呢

闻闻有没有脂肪氧化的耗败气味。如果没有的话证明还算新鲜。一般3年前的油，氧化应该已经很严重了。建议不要吃了。

一袋带壳毛豆放在一起，其中有一小些外壳坏了有个别发霉了，挑其中外壳还好的剥岀来，还能吃嘛！？

如果有任何东西发霉了，尽量不要吃！！！有很大风险！！！

爸妈做的卤牛肉放冷冻室冷冻了几个月能吃吗…

如果是做好马上放冷冻，用袋子装好保证不跟外界接触，保证冷冻条件的情况下，问题不大

冰淇淋放的太久能吃吗？

如果保证冷冻条件，过期不太久，没有异味的话，问题不大。

在电视柜缝隙处发现的那个过期一个半月的鲜花饼，还能吃吗？12天的保质期。我云南人，这时候真的很需要精神鼓励

12天保质期属于短保食品，过期一个半月太久了，有食品安全隐患，建议别吃了。思念云南的话可以多跟家人视频然后他们吃播给你看，就当云聚餐了。

奇奇怪怪的方向

被养死的鱼能吃吗？

建议不要吃，一般你发现它死的时候，它可能已经死了一段时间了。鱼死之后，体内酶催化蛋白质快速分解，微生物繁殖速率很高。因此食用会有很大风险。

死掉的海鲜、贝类、虾蟹等，也尽量不要吃，不仅不好吃，食品安全风险也很大。

另外不是每种观赏鱼都适合食用……

家里有哪些绿植可以吃？

如果你家有种各种香草、香料植物（迷迭香，罗勒，百里香）之类的话，这些香料植物是可以直接拿来做菜的。

如果你家直接种食物，比如辣椒、金桔等，那也没问题。

对于普通观赏植物，不要贸然吃。有些观赏植物（比如水仙、滴水观音等）是有毒的，吃了会中毒。

狗粮/猫粮人能吃吗？

站在食品安全角度，狗粮/猫粮是作为饲料管辖的，跟人类食品在监管上属于两套不同的体系，所以很难说给人吃会不会有问题。但对于比较大的狗粮/猫粮牌子来说，风险应该不大。

但狗粮/猫粮的营养价值对于狗/猫来说是高的，但对于人类来说营养是不均衡的。而且它们通常讨好的是狗/猫的味蕾，站在人类角度来说可能并不好吃。

之前写过：

老坛酸菜牛肉面里的酸菜，用水涮涮后能不能吃？

这个问题扎心了……

我们之前的文章介绍过，「土坑酸菜」确实是非常恶心，吃这种东西也是有一定的食品安全隐患的。

目前我没有把握告诉大家「哪一家的老坛酸菜一定没有问题」。但是非常时刻，如果你实在没其他选择，吃一点，我认为也不至于有非常大的风险。

当然，如果是我的话，我会选择丢弃面里的酸菜包，自己用一些其他食物代替。

经过这次疫情，我们学会了很多储存食物的技能，也知道了平常能开开心心地做一个吃货，是多么快乐且难能可贵。

我把之前写的有关囤货和保质期的文章也放在这里，希望对大家有帮助：

哪些食物可以常温长期保存？

罐头食品为什么放不坏？

关于保质期的知识体系汇总：

大家如果有其他关于「能不能吃」的问题，欢迎留言。

信息茧房

Wed, 23 Feb 2022 10:47:50 CST

最近一个月，无论我打开推特，还是微博豆瓣，每天都被“徐州八孩母亲事件”刷屏。在公司吃工作餐的时候，也和同事聊过这个事件。从我的角度看，此事的热度之高，持续时间之久，近年罕见。能读到我的 blog 这一篇的同学，相信都对这件事的来龙去脉不会太陌生。如果你不了解，那么 google 一下“徐州八娃女”或是“丰县铁链女” 就能找到很多信息。

但是，我很清醒的知道，热度只存在于自己所在的这么个小圈子。我相信在中国社会中，不知道此事的人群才是大多数。就算在微博上百万转发，也不会有所改变。毕竟，翻墙的人还是少数。而墙内的微博微信，都帮助人们把各自的信息茧房建设的很好。

我也看到很多人在努力的线下传播。有人在地铁上向公众发言、多地的书店为丰县八孩母亲案设专柜。但这种信息传播力太脆弱了。只要主流媒体不报道，公众几乎无法了解此事。无需用墙隔开信息，微信之流只需稍使手段，就能协助人自己树立信息之墙。茧房其实是自发建立起来的，技术助了把力。

各位同学，不妨把整件事情在脑海里整理清楚，然后讲给你身边的亲朋好友听听。我相信不少人会诧异你身边人的孤陋寡闻。

中国电信 1 月 25 日宣布 5G 消息正式商用，这意味着什么？它有哪些特点，和「短信」有什么区别？

Thu, 27 Jan 2022 03:07:08 CST

甜草莓的回答

这个问题要从两个方面思考。

站在普通用户角度， 5G消息能实现的功能其实跟目前的各种Message/即时通信服务并无太大差别。如果我们从这一点来看，5G消息的前景一片惨淡，因为众所周知-------运营商的软件研发从来不考虑用户体验，更何况目前大多数即时通信服务生态已经牢不可破。如果专门考虑普通用户市场，依然大概率会被微信/iMessage/Facebook吊锤。

如果我们从网络底层架构升级的角度，它或许会有点发展空间。因为手机短信这种消息方式其实已经远远落后于现代互联网发展。在过去几十年里，语音都从电路域升级到VoLTE/VoNR这种IP交换方式，难以想象的是短信竟然数十年坚持不变？虽然对个人用户来说， 短信目前也就只能拿来收一下验证码。

其实就是拿个人短信来做 实名认证。因为目前互联网成本最低（注意，不是最安全）的个人身份验证方式就是 利用手机SIM卡认证个人身份。从这个角度讲， 5G消息支持富媒体，这样就意味着它天然是实名的，这种方式的可以方便目前很多公司的实名认证。对于银行，政务等等部门，基于5G消息来开发软件，会比普通文本消息更安全且方便，软件也不需要再额外做一次对验证码的文本识别。

但是，这就又回到了原始问题，运营商并没有非常强的软件开发能力，那么5G消息会不会还是最终沦为一个更强大的管道呢？

这个值得思考。

如何摆脱信息茧房？

Mon, 20 Dec 2021 16:18:36 CST

编辑导语：信息茧房是指人们关注的信息领域会习惯性地被自己的兴趣所引导，从而将自己的生活桎梏于像蚕茧一般的“茧房”中的现象。现如今，人们的生活在信息茧房中，线下接触同一类圈子，线上大数据推送相类似的文章。这不是一个好的现象，如何摆脱信息茧房，如何“破圈”，本篇文章作者将告诉你答案，快来阅读吧！

“下次只能光看不点了， 我才夹一筷子，给我推送一桌子”。

早上好王先生：您的体温是38.3摄氏度，体温不正常建议去医院检查；昨天晚上您睡6个小时35分钟，当中醒来3次；其中深度睡眠时间2个小时30分钟，最近注意各项指标…….

上述声音来自我家智能管控系统和手环的反馈，好像把我生活安排的明明白白， 又窃喜又忧愁，为什么？

窃喜的是我可以 随时知道身体数据，及时调整状态；忧愁的是 “我对智能系统的依赖慢慢丧某些大脑能力”，事情只是如此简单吗？不是的。

如果我告诉你，除书和电影外， 我们的职业和人生选择都被塞进可被预知的黑匣子中，你会相信吗？也许多数人都这句话有些茫然，不妨来具体下：不仅是青年，现在的老人和孩子在闲暇时都喜欢抱着手机刷个不停，形容难听点是“像中毒了一样”。

大量的信息流平台正在通过算法偏好来迎合我们，向自身投喂相似的内容，它会造成什么呢？

一方面会让自身 固定在某个信息圈子中难以逃出，它持续强化你对某些问题的看法， 最后形成价值观。

另一方面信息堆积越多， 注意力就难以集中在那些复杂的问题上，造成判断力下降，怎么办？

除此外，身边的一切智能设备仿佛也都在尝试主动为你“提供服务”，这不是坏事；但有一些会让我们在不知觉中陷入信息茧房，不妨重新认识下它。

一、信息茧房

我们先来看看它的由来。

2001年美国学者凯斯·桑斯坦（Cass R. Sunstein）在《信息乌托邦——众人如何生产知识》中提出此概念，并针对内容做出分析和讨论，具体指：

人们的信息领域会习惯地被自身的兴趣所引导，从而将生活桎梏于像蚕丝般一样的「茧房」中的现象。

这个词汇的源头可以追溯到一本新闻传播专业考研必读的书籍，美国计算机科学家、麻省理工学院教授，尼葛洛庞帝的 《数字化生存》，它为什么这么厉害呢？

要知道，20世纪90年代中后期，中国开始兴起互联网创业大潮，年轻的互联网创业者们纷纷有感机遇来临，但对能否把握住这份机遇却心存忐忑，它的出现犹如“盲人指路”， 被奉为互联网时代的「指路圣经」。

令人惊讶的是：25年后的今天在打开书中多半描述已经成为现实，主要围绕三个阶段的预言：

从原子到比特；
代理人界面；
后信息时代。

1. 第一阶段

我想，上过初中三年级的人应该都熟悉，在化学中原子是变化中最小的微粒；如果你不懂没关系，可以用文科的方式理解： 世界万物都是由原子构成，原子组合后构成分子，分子就像瓦砖，堆成各种物质。

它也是人类最经典且使用最广泛的基础假设，用来精准的解释物理学中的力学，热力学、光学、量子学等多方面的问题，甚至还能解释自然科学中的生物学等等。

而尼葛洛庞帝看来，上世纪90年代，大多数信息都是以「原子」的形式呈现，例如：录像带、杂志、报纸、和书籍，长期以来大家对此也习以为常。

但随着计算机技术的发展，即时的电子数据传输就会成为主流的传播方式，我们进而进入比特（binary digit，简称BIT）组成的世界。

原因在于信息是最小单位，它没有重量能以光速方式快速传播，并且无成本拷贝并不会被区域所隔。

这种新的方式能帮助信息摆脱时空的限制，成为全球共享资源，为各个领域的发展带来便利，同时也能促进互联网和计算机的普及。

2. 第二阶段

在上世纪90年代美国计算机学界还是程序设计语言、操作系统和网络协议天下时，尼葛洛庞帝召集一帮各领域专家创立家「媒体实验室」的机构，聚焦研究人机互动。

当时人们把计算机研究重点主要放在 “人如何使用它”并没有关注 “如何和计算机更好相处”。

而基于此问题，他又提出新的概念为 “计算机设计需要人性化界面、此界面应该是使用人代理模式”，什么意思呢？

电脑界面必须像你的管家助手那样能够认识你，了解你的爱好、品位、倾向与需求；甚至还要知晓你的社交朋友圈、理解你的表达语言和肢体动作。

非常厉害吧，为此当时他认为 触屏技术、眼球追踪、语言识别甚至互联网人格的相关研究会是大趋所势，目前看来这些在现在均已经实现。

3. 第三阶段

尼葛洛庞帝在上述基础上，进一步设想了智能计算机将为人类生活带来巨大改变。

他预言到下一步互联网会进入「极端个人化的信息时代」，即算法推荐；在后信息时代里，电脑、手机APP会基于它对你的了解为自身推荐定制化信息。

从前，大众媒体把一模一样的信息通过广播或电视无差别的推荐给每个人；而未来APP会主动对信息进行筛选，并通过界面为使用者制作独一无二的“个人摘要”。

那么，如果按照此指导手册发展，这意味着什么呢？

这不仅让我心中一惊喜，目前买很多电子设备都不用看使用说明书都可以「语言、行为」控制它，以后岂不是更方便么？

但尼葛洛庞帝认为，美好未来虽到来也会在不知不觉中侵蚀人们的智慧和知识；比如：工作机会的减少，导致更多互联网创业者借助线上平台创造更多知识来与企业协同。

背后意味着复杂的工作交给机器解决，人类创作性工作将很难一步登上山顶，甚至非常优秀的创作也很难人性化的被发现，与此未来你可能更多的是和“机器交流”。

那么，严重的是机器取代大部分人力的潮流必不可当，针对发展肯定力大于弊；更加严重的是随着算法推荐带来的信息茧房和数字鸿沟，会加深一个人与另一个人的距离感。

比如：你习惯看历史知识，平台围绕历史中心化展开；若一个天天看娱乐的人被推送的都是八卦，甚至像我这种经常搜“学习内容”的人， 试想下种种场景“会带来什么后果”呢？

我们很难逃出“习惯的周边三公里”。如果不经过主动思考判断或故意去搜寻，会陷入知识获取单一化，没有社会统一认识中，严重者还会造成与社会和企业脱节。

一个现实的案例是：我看到很多离职3个月以上的人，与他们沟通就已经陷入自身的“信息茧房”，对跨岗一丁点技能还能理解，对跨公司业务就直接出现“黑匣子状态”。

不可否认，我们正在经历尼葛洛庞帝教授第三阶段的预测；人们无法阻止数字化的变化，它就像无法对抗大自然一样；但至少每个人可以了解它是如何形成的？如何一步一步吞噬着人们独有的思考模式。

当然，这一切背后离不开人们常说的“算法”或者“个性化推荐”，但它并不是罪魁祸首；那它是什么呢？给自身带来哪些影响呢？

二、算法原理

从框架而言，推荐系统一般包含“召回”和“排序”两方面。

不论是信息还是消费类电商平台，多半以此类型来训练用户，而算法又基于 「内容」和「用户行为」两大类别展开。

我们知道普通人的思维方式分为两种类型：

线性思维；
非线性思维。

前者是把认识停留在对事物的抽象而非本质上，并以这样的抽象为出发点，片面、直线的解释某件事；后者是把认识停留在对事物的抽象层并以基石出发来看底层原理。

机器学习方式和人相似，也分为线性和多种思维（学习）模型， 最主要区别是一方面偏向基础原理，一方面偏向多元化加工；从专业角度出发市面一共有6种常用方式：

过滤算法；
矩阵算法；
因子分解机；
逻辑回归；
梯度提升决策树；
深度神经网络过滤。

它们用在什么位置呢？

要知道，人们看到的所有信息均展示在APP的首页或分类上，在推荐系统中它们属于最上层的展示层， 算法属于中间层，数据是最底层；而 算法的主要功能就是排序和召回，上述的六种模型均服务它们两者。

举个例子：我们经常使用某款APP，它习惯性的抓取自己点击的每个图片或者下方的内容，然后以此用打标签的方式归类在后台中，该行为属于排序，进一步说平台可以收集一个账号的多个标签排序。

可当自身许久没有打开该APP时，机器就基于自身感兴趣的内容，通过push，短信的方式召回我们。

大部分大平台（小红书、抖音、快手）的推荐系统分人工干预和自动推荐两种，前者顾名思义人来操作，后者是给机器设定固定时间来循环使用。

自动推荐是什么呢？

若进一步展开解释，如抖音和头条的监督学习算法 Y=F(Xi ,Xu ,Xc)，这三个函数包含三个维度的变量分别为：

内容；
用户特征；
环境特征。

三者匹配起来是一个复杂的数学问题；市面常用模型有好几种，字节系无非是把多模型混合使用，简单来说就是： 你是谁、你在哪里、你爱看什么？基于这些给你推荐什么。

一般当推荐系统的自动化运作时，它就像山头巡视的小兵，不断从整个物品或者信息聚合中抽取当次需要查询的候选集；根据各种不同维度，如物品、年龄、性别、爱好，场景等种类以及规模的大小对候选集进行推送。

此场景犹如流水线工作的「抽样检查」，也同样用在大部分平台的召回手段上， 具体策略是什么样呢？

其一：内容过滤（Content Filtering）；
其二：协同过滤（Collaborative Filtering）。

资讯类产品的内容审核是不可缺失一部分，主要目的是确保无低质庸俗，保持平台该有的调性； 通常有“先发后审”和“先审后发”两个原则。

场景较轻如网易云，QQ音乐此类阅读、听歌类产品通常是前者；对社区论坛、偏观点讨论、树立权威通常是后者； 因此内容抽检或过滤的基础也是查敏感关键词、重复度、IP发布次数等权重指数。

协同过滤是基于已知部分用户或部分物品的偏好或评分，预测缺失偏好或评分的一种方法。

从切入点上，则可分为基于 “去邻域”的方法（本地生活类平台使用居多）和 隐语义模型（给每个分类中不同维度标签的人进行推送），比较难理解对不对？

举个例子：跟朋友聚餐会习惯性打开美食点评平台去搜索周边餐厅，过程中我们能看到按照公里排行的推荐、也有部分商家的竞价广告。

疑问的是，你会发现那些广告的美食是自己日常爱吃的，并且区域也不是太远，为什么会这么做？

因为可以基于“邻域”做精准的推荐，以此满足用户多频次的消费和深度洞察；如果把“邻域”比作数学的“2”，它左手链接“1”，右手链接数字“3”。

去邻域算法就是把“1”推荐给“3”， 假设不做去中心化折中结果就是上述你看到场景，基于自己搜索习惯、爱好、距离做折中推荐。

对于人工干预比较容易理解，基础的说我基于某类标签做手动推送，如：性别类型、兴趣爱好、话题、KOL量级等。

高维一点会融会贯通几项不同的数据综合考量，好比针对女人中对护肤话题感兴趣，客单价又在多少区间等。

这种方式常见在中小型（百万级用户量）以上的平台，主要特征表现在技术的基础建设已经完成，属于发展中期还完全不能依靠自动化解决。

一方面防止有巨大漏洞出现，造成损失。

另一方面也能运用人工的方式灵活多维度的基于用户（商品）进行推送，比如基于点击率作为推荐指标时，排序算法筛选后，我们会以预测结果为目标。

这些场景中就会用到因子分解，逻辑归因，梯度提升决策树，以及各种神经网络算法，这一切也把它称之为“混合模型”。

但不管怎么样始终都离不开那两大原则“基于用户行为”和“基于内容”； 综合上述，我们能得到什么启发呢？

企业招聘大量研发人员，利用理科的思维逻辑将人的行为特征变成“数据化”，由数据进行颗粒化，最终通过个性化的分析让平台更了解每个人，也就有了那句感同身受的话 “我都没有平台了解我自己”。

但真的是这样吗？这种理解就狭隘了。

你以为平台很了解自己？其实我们不过是把爱好，需求形成的特征进行标签化沉淀在平台上，这造成推荐的内容都在自身的“认知圈内”。

简而言之，每个人在头部资讯（购物）平台看到的展示页均不同， 他代表一个人的视野和爱好，这仿佛似一面镜子疯狂的为你展现热爱的一面，它带来的利弊也是极为可见。

三、孰是孰非

从优劣上有两个方面： 一是良好的认知能力，二是陷入回音室效应。

如果我们能够正确认知到信息茧房如何由来的，或者算法如何基于自身的各种行为形成“虚拟人设”为你定做线上画像；加上我们能够辨别哪些信息是优质的，哪些是不能为我所用， 那就不存在“茧房”。

这就给我们最大的启示是， 很多时候我们听到的未必都是正确的，只有深入并全面了解才会摆脱困境。

比如：很多人拼命的为摆脱算法的囚笼在平台看内容不点赞、不评论、不互动；这就能摆脱它吗？并不能。

反而会为你推荐一大堆乱八七糟的内容让自身眼花缭乱失去对关键信息的辨别的能力。

换句话说， “信息封闭环境”听起来是坏事，这好像人们无法接受其他信息一样，可实际上，这也是一种很常见的现象不是吗？

在没有互联网时，世界上的信息同等无穷尽，新的信息也在产生旧的信息也从未消失，堆积依然很多； 即便人用上一生的精力学习也是有限，真正有所造诣的人都是在冰山上抓住某个一角。

进一步而言，五花八门的信息看始终是看不完的，似乎看来人们不但没有损失什么，反而还让人愈发的认为筛选、寻找自身热爱、匹配自我不同阶段是当下不可缺失的能力。

何况很多时候，各种娱乐类、偏社交短内容平台的push大概率是琐碎事，真正重要的信息你一定会接收到。

假如我们不知道“信息茧房”的概念， 在劣势方面可能会形成持续受害而毫无觉察的状态，这就容易陷入回音室效应中，它有四个关键因素：

隔离；
观点极致化；
观点同质化；
同样信息重复传播。

在隔离角度你可以把它理解成在固有群体或“小圈子”内几乎与外界不怎么交流。

由于没有外部或不同信息进来，内部观点会重在重复传播中不停的在人们心中巩固，促使人们看到与内部观点不同的观点时尽可能否定，从而达到“极端共鸣”。

举个例子：很多人热爱进不同的付费社群来学习，圈子中往往会强调一种东西叫 “价值认同”或“主题认同”，假设某个行为（主题）触发大部人群友的爱好或行为底线，那你可能就会被移除群聊。

当所有人的观点都趋同，那同样的信息传播，变着不同的人去表达意思也就发生多变可质量本身并未提高， 对个人的成长也并没有太大帮助。

这四个关键表现，很好的解释了信息与受众的思维关键；具体而言，回 音室效应不但可以让一个人思维禁锢，还极有可能直接废掉理性思考能力。

根据调查很多受害者是两种状态，一是不乏高等教育的专家学者，二是分辨自控力不高的人。

前者学习几十年光理论不实践，很容易陷入封闭状态中，这种原地踏步造成与现实社会脱节还沉浸在固有的圈子中“津津有味”，殊不知外界已经发生巨大的变化。

后者是那些经常以 “这样学习就是对”“哪个专家说”作为标榜或处事依据的人，他们不习惯以理性的事实为基础，更容易陷入感性层。

正是陷入自己编织的信息茧房之中，才会不停阅读内容高度重复却几乎毫无营养的资讯，这造成自己的认识很难提升到新的层级，不仅荒废了自己还浪费掉整个人生。

种种行为在我看来，所谓的相对封闭环境，即可以是被动也可以成为主动。

被动是别人提供而主动在自己；如改变你获取信息的渠道、屏蔽无效信息、把它们变成高质量这是一种选择。

因此我们所避免的信息茧房可能是错的， “摆脱”不是目的，如何有效的利用它为自身做增值才是最重要的；那如何做呢？有2个认知1个技巧是我在践行的。

四、三个锦囊

掌握的概念越多加上日常灵活运用，才能够减少过错的概率。

有句话叫做 “人无法赚到自身认知之外的钱”，相对的是 “人无法碰到自身认知水平之外的问题”，那么，现在碰到的问题就是自己现阶段的一个上限，具体改变上你可以进行参考：

1. 微调认知基模

基模是人与生俱来的行为模式会随着成长而变化， 它是一种知识分类体系，呈层次化结构，类似于树状图；一般来说并不以某个具体事例为对象，而具有某种程度的一般化和抽象化的性质。

比如可以将方法论提炼成为规律，将规律用在不同领域，它们彼此间都是有关联和结构，只是我们从未发现；并不是凌乱互不相关的保留在记忆中。

1973年，美国学者罗伯特·阿克塞尔罗德在《认知与信息处理过程的基模理论》一文中，提出信息处理的过程模式的解释：它认为 “当我们接触到一个新的事物或者信息时，我们头脑中的相关基模就被激活，参与到信息处理的每个环节当中”。

进一步说：当信息的各项特征与我们认知基模相吻合时，人习惯用原有的解释和态度对待它；当不吻合时，才会对新旧信息进行比较，补充新信息确保新解释和态度。

如果你认识到就会发现，新信息处理结果对认知基模会产生两种影响，其一对旧行为认知的强化，假如有矛盾即使修正形成新基模；其二新信息的处理，会让自己做出分析，推理和判断。

从发展来看，只有不断接触新信息，认知基模才会发展出分支或做结构调整，这也符合神经心理学中“神经元集群（neural ensemble）的解释”。

2. 改善偏食情况

很多人喜欢给自己贴标签，当然他们都有一套逻辑自洽的理论，我不反对也不赞成；我原来也是现在基本不在乎，从我的角度出发往往给的心得是 “年轻不要随意贴标签”，为什么呢？

标签会植入到心智中，无形中渗透自身要往哪个圈子发展、学习什么类型的内容等；这很容易造成“信息偏食”，它会局限的将自我定位。

有人说聚焦不好吗？正确的聚焦在我看来先有中长期目标，如结合3年-5年规划再看当下。

第一方面，人与标签唯一不同在于前者是动态发展后者是静态呈现；今年认为对的，明年可能就会失效。

标签是手段，假设自身认为某个标签在短时间能够让自己有个质的提高，或通过此力量能带来外界优势，反之是不错的选择。

第二方面，即使通过标签或圈子渗透到某个领域中，自身也需要对领域的知识有全面的认知，不要盲目地跟随别人的意见和建议，这样， 受社交媒体下“群体性孤独”的影响几率会不断减少。

那么，对于多元化信息的获取和构建“多元化”的圈子，都是摆脱信息茧房必要的手段，我近些年一直这样才能横跨不同的领域。

3. 多看多听多动手

这句话的具体意思为 “尽可能删掉自己历史浏览痕迹”，遇到喜欢的内容把它立马记录下来或转存在收藏中；这可确保自己看到的内容不是经过刻意被推荐，而是相对随机的。

此方法好处是可以非常立竿见影的起效，坏处是你始终还很难完全避免掉“被种草”，那怎么办呢？

多动手去各种平台获取信息，并非“多动手点赞”；这样可以避免单个平台的误导；就我个人而言，因为我有阅读习惯，所以经常通过RSS（信息聚合）阅读完当天所有新闻。

古人云： 兼听则明，偏信则暗。当自身做到多渠道、全方位的获取随机性的信息时，信息茧房就会失去存在的基础，自然就会不攻自破。

总而言之，它仍然是可被破解和避免的，主要是积极主动行动起来，放弃固有习惯，这可能会让自身逃离舒适区，变得不那么愉快； 我想，比起收益这点付出还算值得。

五、总结一下

最厉害的并不是所谓平台方“算力”或“数据”有多牛，而是人； 不信你想想，平台的技术会磨灭我们看世界的好奇心吗？

并不会，平台多元的分发口径，没有成为“茧”，反而织了一张“网”；而 让自身看到的信息能成为茧房，或许这件事只有自己能办到，不是吗？

作者：王智远

本文由公众号：王智远（ID：Z201440）授权发布于运营派。未经允许，禁止转载

题图来自 Unsplash，基于CC0协议。

便利蜂大规模采集目标店铺附近的所有信息

Sat, 18 Dec 2021 20:49:08 CST

《南方周末》报道（付费墙），连锁便利店便利蜂使用摄像头大规模收集目标店铺附近的所有信息，引发了隐私方面的争议。便利蜂只用了 3 年就开了 2000 家分家，它采用的一种方法是使用摄像头采集信息，这种信息采集被称为贴拍。报道称，进入一座城市之前，便利蜂首先会派出信息采集团队，按照城市人口选定相应比例的写字楼进行无差别拍摄，这一轮地毯式的贴拍被称为“预采”。这一轮采集的写字楼，完全是随机选取。进入这座城市后，会开始有针对性地“新址采集”，以目标店铺为中心，附近范围内的所有设施要素都要拍，具体范围由负责选址开发的运营部门划定。这些设施要素包括酒店、医院、学校、培训机构、购物中心、专业市场、政府机构、电影院、健身房、底商、酒吧、网咖、会展中心、体育场馆、音乐馆、剧场剧院、青少年宫、KTV、其他（如地铁出入口）。“贴拍”涉及一些位于北京的政府机构门口的拍摄...后台数据显示包括商务部、交通部、环保部、国家旅游局、国家文物局、海关总署等。部分央企、中央媒体，比如中石油、中石化、国家电网、国开行、光明日报等也在其中。北京写字楼的数据是这些数据中最为庞大的一项，几乎实现了对北京五环以内所有办公楼的覆盖，这项数据的总量高达约 43000 条，上海只有北京的一半，约 20000 条。

Spring Cloud Feign如何实现JWT令牌中继，传递认证信息？

Thu, 21 Oct 2021 10:47:21 CST

在上一篇实现了 Spring Cloud资源服务器的定制化，但是又发现了一个新的问题，Spring Cloud微服务调用的过程中需要令牌中继。只有令牌中继才能在调用链中保证用户认证信息的传递。今天就来分享一下如何在Feign中实现令牌中继。

令牌中继

令牌中继(Token Relay)是比较正式的说法，说白了就是让Token令牌在服务间传递下去以保证资源服务器能够正确地对调用方进行鉴权。

令牌难道不能在Feign自动中继吗？

如果我们携带Token去访问A服务，A服务肯定能够鉴权，但是A服务又通过Feign调用B服务，这时候A的令牌是无法直接传递给B服务的。
这里来简单说下原因，服务间的调用通过Feign接口来进行。在调用方通常我们编写类似下面的Feign接口：

@FeignClient(name = "foo-service",fallback = FooClient.Fallback.class)     
public interface FooClient {     
    @GetMapping("/foo/bar")     
    Rest<Map<String, String>> bar();     
     
    @Component     
    class Fallback implements FooClient {     
        @Override     
        public Rest<Map<String, String>> bar() {     
            return RestBody.fallback();     
        }     
    }     
}

当我们调用Feign接口后，会通过动态代理来生成该接口的代理类供我们调用。如果我们不打开熔断我们可以从Spring Security提供SecurityContext对象中提取到资源服务器的认证对象JwtAuthenticationToken，它包含了JWT令牌然后我们可以通过实现Feign的拦截器接口RequestInterceptor把Token放在请求头中，伪代码如下：

/**     
 * 需要注入Spring IoC     
 **/     
static class BearerTokenRequestInterceptor implements RequestInterceptor {     
    @Override     
    public void apply(RequestTemplate template) {     
    final String authorization = HttpHeaders.AUTHORIZATION;     
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();     
                 
        if (authentication instanceof JwtAuthenticationToken){     
            JwtAuthenticationToken jwtAuthenticationToken = (JwtAuthenticationToken) authentication;     
            String tokenValue = jwtAuthenticationToken.getToken().getTokenValue();     
            template.header(authorization,"Bearer "+tokenValue);     
        }     
    }     
}

如果我们不开启熔断这样搞问题不大，为了防止调用链雪崩服务熔断基本没有不打开的。这时候从SecurityContextHolder就无法获取到Authentication了。因为这时Feign调用是在调用方的调用线程下又开启了一个子线程中进行的。由于我使用的熔断组件是Resilience4J,对应的线程源码在Resilience4JCircuitBreaker中：

Supplier<Future<T>> futureSupplier = () -> executorService.submit(toRun::get);

SecurityContextHolder保存信息是默认是通过ThreadLocal实现的，我们都知道这个是不能跨线程的，而Feign的拦截器这时恰恰在子线程中，因此开启了熔断功能（circuitBreaker）的Feign无法直接进行令牌中继。

熔断组件有过时的Hystrix、Resilience4J、还有阿里的哨兵Sentinel，它们的机制可能有小小的不同。

实现令牌中继

虽然直接不能实现令牌中继，但是我从中还是找到了一些信息。在Feign接口代理的处理器FeignCircuitBreakerInvocationHandler中发现了下面的代码：

private Supplier<Object> asSupplier(final Method method, final Object[] args) {     
  final RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();     
  return () -> {     
   try {     
    RequestContextHolder.setRequestAttributes(requestAttributes);     
    return this.dispatch.get(method).invoke(args);     
   }     
   catch (RuntimeException throwable) {     
    throw throwable;     
   }     
   catch (Throwable throwable) {     
    throw new RuntimeException(throwable);     
   }     
   finally {     
    RequestContextHolder.resetRequestAttributes();     
   }     
  };     
 }

这是Feign代理类的执行代码，我们可以看到在执行前：

final RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();

这里是获得调用线程中请求的信息，包含了ServletHttpRequest、ServletHttpResponse等信息。紧接着又在lambda代码中把这些信息又Setter了进去：

RequestContextHolder.setRequestAttributes(requestAttributes);

如果这是一个线程中进行的简直就是吃饱了撑的，事实上Supplier返回值是在另一个线程中执行的。这样做的目的就是为了跨线程保存一些请求的元数据。

InheritableThreadLocal

RequestContextHolder 是如何做到跨线程了传递数据的呢？

public abstract class RequestContextHolder  {     
     
private static final ThreadLocal<RequestAttributes> requestAttributesHolder =     
new NamedThreadLocal<>("Request attributes");     
     
private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder =     
new NamedInheritableThreadLocal<>("Request context");     
// 省略     
}

RequestContextHolder 维护了两个容器，一个是不能跨线程的ThreadLocal，一个是实现了InheritableThreadLocal的NamedInheritableThreadLocal。InheritableThreadLocal是可以把父线程的数据传递到子线程的，基于这个原理RequestContextHolder把调用方的请求信息带进了子线程，借助于这个原理就能实现令牌中继了。

实现令牌中继

把最开始的Feign拦截器代码改动了一下就实现了令牌的中继：

/**     
* 令牌中继     
*/     
static class BearerTokenRequestInterceptor implements RequestInterceptor {     
private static final Pattern BEARER_TOKEN_HEADER_PATTERN = Pattern.compile("^Bearer (?<token>[a-zA-Z0-9-._~+/]+=*)$",     
Pattern.CASE_INSENSITIVE);     
     
        @Override     
        public void apply(RequestTemplate template) {     
            final String authorization = HttpHeaders.AUTHORIZATION;     
            ServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();     
            if (Objects.nonNull(requestAttributes)) {     
                String authorizationHeader = requestAttributes.getRequest().getHeader(HttpHeaders.AUTHORIZATION);     
                Matcher matcher = BEARER_TOKEN_HEADER_PATTERN.matcher(authorizationHeader);     
                if (matcher.matches()) {     
                    // 清除token头 避免传染     
                    template.header(authorization);     
                    template.header(authorization, authorizationHeader);     
                }     
            }     
        }     
    }

这样当你调用FooClient.bar()时，在foo-service中资源服务器(OAuth2 Resource Server)也可以获得调用方的令牌，进而获得用户的信息来处理资源权限和业务。
❝

不要忘记将这个拦截器注入Spring IoC。

总结

微服务令牌中继是非常重要的，保证了用户状态在调用链路的传递。而且这也是微服务的难点。今天借助于Feign的一些特性和ThreadLocal的特性实现了令牌中继供大家参考。原创不易，请大家多多点击再看、点赞、转发。

好了，今天的学习就到这里！如果您学习过程中如遇困难？可以加入我们超高质量的 Spring技术交流群，参与交流与讨论，更好的学习与进步！更多 Spring Cloud教程可以点击直达！，欢迎收藏与转发支持！

数学建模信息收集

Tue, 19 Oct 2021 07:26:00 CST

其实我和大多数加入数学建模社团的人目的都一样，有些功利吧，想要通过参加数学建模竞赛整点综测分，但也有一些想要通过参加数学建模的比赛来提升数学和编程能力的想法。和其他大多数加入数学建模社团的人一样我对数学建模并不是特别了解，在我没有查阅资料之前我对数学建模只有一些模糊的认识通过数学来解决实际问题并利用编程推广证明模型（我自己的认识当然不太准确）。然后我利用了一个下午和晚上进行了信息检索收集和整理，废话不多说进入正文。

序

本文全部资料全来自互联网，我仅对其进行整理总结。本文主要从下几个方面进行总结，什么是数学建模？参加数学建模竞赛的意义？有哪些常见的比赛？关于参赛组队相关问题？需要准备什么？其他问题的整理。由于整理收集的时间并不长，后续估计还会添加或者修改。

数学建模是什么？

先来看看百度度娘给的定义吧！数学建模，就是根据实际问题来建立数学模型，对数学模型来进行求解，然后根据结果去解决实际问题。不论是用数学方法在科技和生产领域解决哪类实际问题，还是与其它学科相结合形成交叉学科，首要的和关键的一步是建立研究对象的数学模型，并加以计算求解（通常借助计算机）；数学建模和计算机技术在知识经济时代的作用可谓是如虎添翼。引用自百度百科数学建模词条。

数学建模，简单来说就是使用数学符号对于某些事物进行抽象和模拟。数学建模，狭义上来讲是就是从实际问题中抽象出数学模型的过程，在广义上而言，数学建模又包括了狭义上的数学建模（我们可以理解为模型的设计过程）以及后续的计算求解与分析等。讲了一大堆，你看懂了吗？没有看懂，有关系吗？没有关系，我也没看懂（大雾）。

讲一句大家都听得懂的人话吧，数学建模用通俗易懂的话讲就是“1到3个人组队，从3~4个“应用题”中选出一个题，之后独立或在指导老师的指导下，在三天三夜（一般是这么长时间）的时间里，建立一个数学模型来解这道题，最后将你们的数学模型、解题思路、方法、过程以及最终结果以论文形式呈现出来（别担心，论文也有具体格式要求，按部就班的填充即可）。”

参加数学建模竞赛的意义？

1.数学建模的获奖比率和比赛的频率高，只要掌握一定的方法，就可以获得很多奖，而比赛获奖对保研而言尤为重要

2.数学建模可以锻炼你的逻辑思维和团队协作能力，能让你结交一些“真朋友”。

3.获奖的论文稍加修改就可以向一些相关的期刊杂志进行投稿，而且中稿的可能性也会较大

4.建模当中使用的方法对研究生阶段写论文非常有帮助

5.越来越多的高校开始看重数学建模，对研究生复试也会有很大帮助。

6.有的企业在面试的过程中也会着重看你的建模比赛，所以对就业也有一定的帮助。

7.最重要的一点，数学建模性价比高，因为比赛就三天三夜，比赛所用的知识基本上就是你这三天所学习的知识，所以说，虽然过程“痛苦”一点，但是相比于创青春、三创赛之类的团队比赛而言，占用的时间还是少的多，而且获奖比率也会更高。真•一次参赛终身受益。

数学建模相关赛事

国家级

1、 MCMICM :美国大学生数学建模竞赛(每年2月份左右,变动大,四天,国内认可度大,国际认可度大)（在网上看到说由于19年的一个事件导致国内一些院校不再认可这个比赛）

2、 GUMCM:全国大学生数学建模竞赛（每年九月中旬一个周五到周末三天72小时，国内认可度大，国际一般）

3、 GMCM :研究生数学建模竞赛（本科生可以参加）(从9月24日上午8时开始,至9月28日中午12时结束国内认可度高国外一般）

4、 EMCM :中国电机工程学(电工)杯数学建模竞赛(每年5月27日上午8时至5月30日上午8时,三天,国内认可度一般,国际一般)

5、 MathorCup: 大学生数学建模挑战赛(每年5月27日上午8时至5月30日上午8时,三天,国内认可度低,国际认可度低)

6、 APMCM :亚太地区大学生数学建模竞赛(每年11月17号上午八点到21号上午八点,四天,国内认可度低,国际认可度低)

省级、地区级

1、 苏北赛:(每年5月1号上午八点到5月4号上午八点,三天,国内认可度高,社会认可
度一般)
2、 TZMCM :数学中国数学建模网络挑战赛(每年4月中旬,三天,国内认可度一般、
社会认可度高)
3、 CAMCM :数学中国数学建模国际赛【俗称小美赛】(每年11月24号上午八点到11月28号上午八点,四天,国内认可度一般、社会认可度高)
4、 华东邀请赛(每年5月19号到5月22号,三天,国内认可度一般、社会认可度一般).5、东北赛(每年4月18号到4月21号,三天,国内认可度一般、社会认可度一般)
6、 华中赛(每年04月30日上午8点到5月3号上午八点,三天,国内认可度低、社会认可度低)

时间一览表

（3）时间一览表
2月中旬: MCM / CM :美国大学生数学建模竞赛（★）

4月中旬: TZMCM :数学中国数学建模网络挑战赛

4月18号:东北三省大学生数学建模联赛

4月30号:华中地区大学生数学建模联赛

5月1号:苏北地区大学生数学建模联赛（★）

5月27号: EMCM :中国电机工程学(电工)杯数学建模竞赛（★）

5月27号: MathorCup 大学生数学建模挑战赛

9月中旬: CUMCM :全国大学生数学建模竞赛（★）

9月24号: GMCM :研究生数学建模竞赛

11月17号: APMCM :亚太地区大学生数学建模竞赛（★）

11月24号: CAMCM :数学中国数学建模国际赛

★标注意味着推荐参加的比赛

关于参赛组队相关问题？

关于组队的一些误区

Q1：我现在才大一或大二，没什么人脉，要不等大三再参加吧！

A1:这也是一个很可怕的想法，为什么这么说呢？

众所周知，数学建模一般是需要三个人组队参加，而这个所谓的“队”是怎么组建起来的呢？

因为你很难一开始就能组好一个队，所以最简单粗暴的方法，就是尽可能的找那些建模获奖或者参加了很多次建模的人组队，而这种队伍一般在大二时就会确定下来，而一旦确定下来之后，不出什么意外，队员就不会再改变了。

所以等你大三甚至大二下学期再去组队参加，你还是很难找到所谓的“大神”，获奖的可能性可想而知。所以递递建议，从大一就开始参加数学建模比赛。

Q2:我是文科生，数学不好，所以不适合参加数学建模。

A2:其实说实话，数学建模虽然带着“数学”二字，但是与数学还真没有非常大的关系。

很多时候，你需要解答的问题里面可能连一个数字都没有，而且你目前所学的数学知识（如果你不是非数学类学生）在建模的过程中基本上都用不到。

所以说，即便你是文科生，就算你高数不及格，也照样不影响你参加数学建模，更何况递递本身就在经管学院（偏文科）。

Q3.其他学院的人我认识不多，要不我就从我们专业随便找两个人参加吧。

A3:这应该是很多建模小白最初的想法，不能说错，但确实有点不妥。

千万不要随随便便找俩人就组队，不光建模，像其他的团队比赛也是，找人组队之前一定要有目的性，不是说关系好就可以一块参加比赛，因为比赛需要的是能力而不是关系。
人员配置是最重要的底牌，请尽量找到合适的队友。不要以亲疏远近为第一出发点，请尽量找有一定基础的同学。数学建模是一个“现学现卖”的过程，如果是从零开始，请务必注意其学习能力和学习态度。

组建队伍

建模需要什么能力，你就应该知道如何组队了。

简单来说，要想顺利完成数学建模，一般需要三种能力，分别是：构建模型、计算机编程、论文写作。

而这三种能力所对应的专业学院大家应该就清楚了，最直接的就是数学学院、计算机学院、经管或文法学院(偏文科学院)。

所以理论上来讲，最好的队伍就应该有这三个学院的同学，但现实中却很难组建一支这种队伍，因为你连本学院认识的人都不多，更何况其他学院的呢。

关于团队构成的心得

团队是极其重要的一个点，我觉得科学合理的团队能够让你事半功倍。首先得是目标类似的，比如都想保研加分或者都想冲击国奖等等，其次就是分工合理、专业互补，数学建模团队一般是由建模、编程和写作组成，先给自己定位，然后可以按着需求去找队友就好啦。

建模的人要懂撰写论文，要先把自己撰写好的”建模部分的论文”用格式工整的语言写好，然后再发给撰写论文的人，不然让写论文的人再改会很麻烦。

写论文的人要懂建模，知道这些公式这些模型怎么写成数学文字才能更好得让人理解。

编程的人要懂建模，建模的要了解编程，这样能在进行辅助计算时节省时间。

所以虽然有所分工，但是实际上小队成员对这三项技能（建模，编程，论文）除了专攻的方向其他也都要有所涉猎才能更有利于合作。

一定要挑选好队友，否则比赛的三天可能就是你一个人建模一个人编程一个人论文，最大可能就是一个人难以坚持最后未完赛弃赛，当然如果你是大腿那当我没说。

需要准备什么？

首先数学建模一个可以分工合作的比赛，一个小组一般由建模手编程手和写作手，三个部分所组成，虽然是分工合作，但是如果大家都对建模有一些基础认识可以达到事半功倍的效果。建模手一般也需要会一些编程知识半个编程手。
建模（编程）、写作、编程。

建模的人一般应该有比较扎实的数理基础，思维活跃，并且同时会编程为最佳。
写作的人应该思维缜密，语言逻辑性强，要能看懂建模人建立的模型，

在理解模型的基础上进行写作。我个人认为 写作是最辛苦的。

1建模基础

了解建模，可以通过B站中国mooc来了解学习B站推荐教程清风数学建模，

2.编程基础

编程基础一般就涉及到模型的计算了，Matlab是必须要掌握的语言，各种技术以及资料都相对比较齐全些。而R，SAS，SPSS这三个统计学语言三选一就足够了，但建议选择前两个，SPSS软件属于傻瓜操作。比赛的时候若有需要完全可以现学现卖。参考书籍《数学建模算法与应用（司守奎）》

3.论文

1.多看获奖论文

2.平时就要制定论文框架以备比赛用

3.不要想着到时候比赛自己只负责论文

4.学习一下latex

5.熟练引用格式

6.练习摘要，练习摘要，练习摘要！

其他问题整理

Q1：写作手是不是只管写作不管建模？建模手、编程手是不是不用管写作？

数学建模的比赛时间非常紧，国赛是三天，美赛是不到五天，因此建模论文没办法确保结论的准确性和推理过程的科学性，在几天时间完成正常科研大半年的工作是不现实的。所以，要明确一点，建模比赛的目的在于体会建模的乐趣，培养建模的兴趣，锻炼建模的技能。因此，建模论文的写作必须“迅猛”，写作手的工作要与建模手、编程手的工作紧密结合在一起，否则就达不到学习的目的。

写作不是写作手一个人的事情，而是所有队员都要参与的事情。理由很简单，如果写作手没有参与建模的讨论和建立的过程，如果建模手没能将建模的过程清晰地表达出来，如果编程手不能对算法的思想和代码的逻辑描述清楚，论文基本上完成不了。所以，每个队员都要进行写作，边做边写，整个建模的全部步骤都要保留痕迹，即使是错误的、无效的工作也尽量写一点东西，对建模结论的得出或许是无用的，但是对文章却很可能成为亮点。

Q2：要不要先把问题讨论清楚然后在进行写作？

A2：不要，因为我的经验告诉我，讨论过程很可能花去两天半的时间。所以，从确定选题以后，就要加紧工作，不要耗费过多时间在讨论细节问题上，不要追求在每个细节的处理上都做到完美，用最短的时间选择出合适的方法，然后马上进行建模的工作，在建模的过程中发现不妥再进行修正。这样做是避免纸上谈兵，只有在实践中才能发现问题、完善思路。即使做了很多无用功，也是不要紧的，耗费的时间不会比嘴头上讨论的时间多，这些无用功也是可以写到论文里的。

Q3：在建模手、编程手都束手无措时，写作手是不是就没事干了？

A3：并不是。写作手是队里从头到尾最忙的一个人，建不了模不代表写不了作。

比如说，一开始的选题，需要考虑不同题目要解决什么问题、属于哪个学科、所需要的知识基础、重点难点、可能用到的模型、算法、大体上的解决思路。选题过程中要对数据的特点进行分析，这时会涉及一些简单的数据处理，形成数据透视表等初等资料。这些都是可以写进论文的。

数学建模中若分成算手，写手，编程手，这三人的具体分工应该是什么？
算手：建模型的。

写手：写论文的。

编程手：写代码的。

这三个任务几乎就是建模的主要构成因素，如此分工听起来非常合理，但实际操作起来，特别鸡肋。

简单来说，写手一开始闲得蛋疼，最后累哭。算手正好倒过来。编程手如果顺利，就会一直很闲，不顺的话又会耽误整个建模进度。

所以还是并联操作吧，比如我们小队当初就是一人写一个模型的（正好建了三个模型）。

并串联结合就更好了，比如开始的时候模型（思路）可以一起想，最后论文（翻译）可以一起写。遇到问题也好互相帮助。

而且Abstract交给一个人完成肯定欠妥啊。

使用python打造自己的信息收集工具 - FreeBuf网络安全行业门户

Thu, 23 Sep 2021 17:36:12 CST

介绍：

该篇章主要介绍如何编写自己的信息收集工具，主要流程如下：

1、向bing搜索引擎发起request请求，获取url数据

2、使用正则表达式对获取的数据进行处理

3、用多线程，对处理的数据进行二次请求，返回标题等数据

4、使用openyxl模块，将数据保存为.xlsx格式

请注意：

该篇章目的是熟悉python编程，学习python的一些常见模块，在编写程序的过程中会有很多操作和方式方法，望大家能共同加油学到东西。本文仅用于技术讨论与研究，这里使用的技术仅用于学习教育目的，如果列出的技术用于其他任何目标，本站及作者概不负责。

本文涉及到模块有：

#coding:utf-8        
import requests     #发起request请求      
import urllib3      #处理请求https异常报错问题      
import re       #使用正则表达式对请求到的数据进行处理      
from optparse import OptionParser   #自定义输入参数      
import threading        #多线程模块      
import queue            #多线程辅助模块，使用队列的方式对多线程进行控制      
from bs4 import BeautifulSoup   #与re类似 使用正则表达式对请求到的数据进行处理      
import time,datetime    #获取当前的时间      
from openpyxl import  * #数据处理，将获取到的数据保存在excel文件中

属性：

heads = {                       #全局变量  请求头      
'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64)                          AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',   #模拟浏览器请求      
'Connection':'close',        
'Accept-Encoding':'gzip, deflate'      
}      
count=1                         #全局变量  用于序号字段      
queueLock = threading.Lock()    #全局变量  使用线程锁处理 线程异常问题      
class DoRun(threading.Thread):  #自定义 多线程运行时使用的类

方法：

def get_Input():    #获取search语句 和 page      
def getUrls(search,page):       #构造搜索语句，在bing搜索引擎搜索数据并返回urls      
def req(url):   #对url进行验证，返回numb,url,title,status      
def init_excel(filename):  #创建.xlsx表格，并初始化内容      
def Save_Date(date,filename):   #将数据存储到表格当中      
def run():     #核心代码

完整代码如下：

#coding:utf-8        
import requests     #发起request请求      
import urllib3      #处理请求https异常报错问题      
import re       #使用正则表达式对请求到的数据进行处理      
from optparse import OptionParser   #自定义输入参数      
import threading        #多线程模块      
import queue            #多线程辅助模块，使用队列的方式对多线程进行控制      
from bs4 import BeautifulSoup   #与re类似 使用正则表达式对请求到的数据进行处理      
import time,datetime    #获取当前的时间      
from openpyxl import  * #数据处理，将获取到的数据保存在excel文件中      
      
heads = {                       #全局变量  请求头      
'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',   #模拟浏览器请求      
'Connection':'close',        
'Accept-Encoding':'gzip, deflate'      
}      
count=1                         #全局变量  用于序号字段      
queueLock = threading.Lock()    #全局变量  使用线程锁处理 线程异常问题      
class DoRun(threading.Thread):  #自定义 多线程运行时使用的类      
def __init__(self,queue,filename):      
threading.Thread.__init__(self)      
self._queue=queue      
self._filename=filename      
def run(self):      
while not self._queue.empty():      
js=req(self._queue.get())      
#print(js)      
queueLock.acquire()      
if(js):      
Save_Date(js,self._filename)      
queueLock.release()              
def init_excel(filename):  #创建.xlsx表格，并初始化内容      
wb=Workbook()      
filename=filename+".xlsx"      
ws=wb.create_sheet(index=0,title="域名")      
head=['序号','域名','标题','状态']      
for i in range(0,4):      
ws.cell(1,i+1).value=head[i]      
wb.save(filename)      
def Save_Date(date,filename):   #将数据存储到表格当中      
filename=filename+".xlsx"      
wb_save=load_workbook(filename)      
ws_save=wb_save.worksheets[0]      
current_row=ws_save.max_row+1      
current_col=1      
for key in date:      
ws_save.cell(date['numb']+1,current_col).value=str(date[key])      
current_col+=1      
wb_save.save(filename)      
def req(url):   #对域名进行验证，返回状态码，title      
global count      
dir={'numb':0,'url':'url','title':'None','status':0}      
stat=0      
title="None"      
      
try:      
urllib3.disable_warnings()      
response = requests.get(url=url,headers=heads,verify=False,timeout=10)   #请求漏洞的url      
if response.status_code == 200:      
bs=BeautifulSoup(response.content,"html.parser")      
title=bs.find("title").text      
stat=response.status_code      
dir['numb']=count      
dir['url']=url      
dir['title']=title      
dir['status']=stat      
count+=1      
print("[+]"+url+"\ttitle:"+title)      
return dir      
else:      
print('[-]请求失败：\t{}\t{}'.format(url,response.status_code))      
except Exception as e:      
print('[-]请求失败: {}\t'.format(e,url))      
def getUrls(search,page):       #构造搜索语句，在bing搜索引擎 搜索数据并返回urls      
count=1      
urls=[]      
url="https://cn.bing.com/search?q={}&first={}"      
for i in range(1,page):      
if(i!=1):      
count=(i-2)*10+9      
url=url.format(search,i)      
try:      
resp=requests.get(url=url,headers=heads)      
html=resp.text      
if(resp.status_code==200):      
res=re.findall(r'<a target="_blank" href="(.*?)"',html)      
for u in res:      
if(u not in urls):      
urls.append(u)      
else:      
print('[-]请求失败：\t{}\t{}'.format(url,resp.status_code))      
except Exception as e:      
print('[-]请求失败: {}\t'.format(e,url))      
      
return urls      
def get_Input():    #获取search语句 和 page      
optParser = OptionParser()      
optParser.add_option('-s','--search',action = 'store',type = "string" ,dest = 'search',help='漏扫文件的目录',default="search_def")      
optParser.add_option("-p","--page", action="store", type="int",dest="page",help='要搜索的页数',default=10)                  
optParser.add_option("-t","--threads", action="store", type="int",dest="threads",help='线程数量，默认为10',default=10)                  
(options , args) = optParser.parse_args()      
return options.search,options.page,options.threads      
def run():                
que=queue.Queue()      
print(datetime.datetime.now())              #打印开始时间      
search,page,thread_count=get_Input()        #获取输入的参数 如searce 、线程数、页面数      
if(search=="search_def"):      
print(r"[-]错误，未输入指定参数：python3 temp.py -s site:qq.com [-p 10] [-t 20] ")      
return      
print(search)      
threads=[]      
urls=getUrls(search,page)     #获取urls      
filename=''.join(re.findall("([a-z,0-9])",search))      #将输入的内容进行处理 ，作为文件的名称      
init_excel(filename)        #创建并初始化excel        
for url in urls:      
que.put(url)            #将获取的urls添加到queue中        
for i in range(thread_count):      
threads.append(DoRun(que,filename))     #使用多线程 默认调用 run()函数      
for i in threads:      
i.start()               #启动多线程      
for i in threads:      
i.join()                #等待线程结束      
      
print(datetime.datetime.now())      #打印结束时间      
run()

使用说明：****

python3 .\bingying.py -s "site:.com" -p 10 -t 30      
Options:      
-h, --help  show this help message and exit      
-s SEARCH, --search=SEARCH    搜索的语法(默认 site:.com)      
-p PAGE, --page=PAGE          要搜索的页数（一页10条数据，默认10页）      
-t THREADS, --threads=THREADS 线程数量，(默认为10)

结果呈现

iPhone 13或支持LEO卫星通信没有4G/5G也能发消息打电话

Mon, 30 Aug 2021 08:13:15 CST

据分析师郭明錤称，iPhone 13将支持低地球轨道(LEO)卫星通信连接，允许用户在没有4G或5G覆盖的地区打电话和发送消息。

在一份致投资者的报告中，郭解释说，‌iPhone 13‌系列将配备能够连接到LEO卫星的硬件。如果启用相关软件功能，这将允许‌iPhone 13‌用户无需4G或5G蜂窝连接即可打电话和发送消息。

据报道，‌iPhone 13‌配备了支持卫星通信的定制高通X60基带芯片。其他智能手机品牌显然要等到2022年才能采用实现卫星通信功能所需的X65基带芯片。

SpaceX旗下的Starlink是一些用户可能已经耳熟能详的LEO互联网连接提供商，但据说最有可能在技术和服务覆盖方面与苹果合作的LEO卫星通信服务提供商是Globalstar。据称，高通一直在与Globalstar合作，在未来的X65基带芯片中支持n53频段。

郭解释说，向用户提供LEO连接的“最简单方案”是个别网络运营商与Globalstar合作。这意味着合作网络运营商的客户可以通过他们的网络运营商直接使用‌iPhone 13‌上的Globalstar卫星通信服务，而不需要额外的合同或付款。

郭表示，苹果公司对卫星通信的发展趋势持“乐观态度”，并在“一段时间”前成立了一个专门的团队来研究和开发与卫星通信相关的技术。

国家网信办关于《互联网信息服务算法推荐管理规定（征求意见稿）》公开征求意见的通知

Fri, 27 Aug 2021 12:53:59 CST

据微信公众号“网信中国”27日发布消息，为了规范互联网信息服务算法推荐活动，维护国家安全和社会公共利益，保护公民、法人和其他组织的合法权益，促进互联网信息服务健康发展，我办起草了《互联网信息服务算法推荐管理规定（征求意见稿）》，现向社会公开征求意见。公众可通过以下途径和方式提出反馈意见：

1.登录中华人民共和国司法部中国政府法制信息网（www.moj.gov.cn、www.chinalaw.gov.cn），进入首页主菜单的“立法意见征集”栏目提出意见。

2.通过电子邮件将意见发送至：jishu10@cac.gov.cn。

3.通过信函将意见寄至：北京市西城区车公庄大街11号国家互联网信息办公室网络法治局，邮编：100044，并请在信封上注明“互联网信息服务算法推荐管理规定征求意见”字样。

意见反馈截止日期为2021年9月26日。

附件：互联网信息服务算法推荐管理规定（征求意见稿）

国家互联网信息办公室

2021年8月27日

附件如下：

互联网信息服务算法推荐管理规定（征求意见稿）

第一条为了规范互联网信息服务算法推荐活动，维护国家安全和社会公共利益，保护公民、法人和其他组织的合法权益，促进互联网信息服务健康发展，弘扬社会主义核心价值观，根据《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》、《互联网信息服务管理办法》等法律、行政法规，制定本规定。

第二条在中华人民共和国境内应用算法推荐技术提供互联网信息服务（以下简称算法推荐服务），适用本规定。法律、行政法规另有规定的，依照其规定。

前款所称应用算法推荐技术，是指应用生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类等算法技术向用户提供信息内容。

第三条国家网信部门负责全国算法推荐服务的监督管理执法工作。省、自治区、直辖市网信部门依据职责负责本行政区域内算法推荐服务的监督管理执法工作。

第四条算法推荐服务提供者提供算法推荐服务，应当遵守法律法规，尊重社会公德和伦理，遵守商业道德和职业道德，遵循公正公平、公开透明、科学合理和诚实信用的原则。

第五条鼓励相关行业组织加强行业自律，建立健全自律制度和行业准则，组织制定行业标准，督促指导算法推荐服务提供者建立健全服务规范、依法提供服务并接受社会监督。

第六条算法推荐服务提供者应当坚持主流价值导向，优化算法推荐服务机制，积极传播正能量，促进算法应用向上向善。　　

算法推荐服务提供者不得利用算法推荐服务从事危害国家安全、扰乱经济秩序和社会秩序、侵犯他人合法权益等法律、行政法规禁止的活动，不得利用算法推荐服务传播法律、行政法规禁止的信息。

第七条算法推荐服务提供者应当落实算法安全主体责任，建立健全用户注册、信息发布审核、算法机制机理审核、安全评估监测、安全事件应急处置、数据安全保护和个人信息保护等管理制度，制定并公开算法推荐相关服务规则，配备与算法推荐服务规模相适应的专业人员和技术支撑。

第八条算法推荐服务提供者应当定期审核、评估、验证算法机制机理、模型、数据和应用结果等， 不得设置诱导用户沉迷或者高额消费等违背公序良俗的算法模型。

第九条算法推荐服务提供者应当加强信息内容管理，建立健全用于识别违法和不良信息的特征库，完善入库标准、规则和程序。发现未作显著标识的算法生成合成信息的，应当作出显著标识后，方可继续传输。

发现违法信息的，应当立即停止传输，采取消除等处置措施，防止信息扩散，保存有关记录，并向网信部门报告。发现不良信息的，应当按照网络信息内容生态治理有关规定予以处置。

第十条算法推荐服务提供者应当加强用户模型和用户标签管理，完善记入用户模型的兴趣点规则，不得将违法和不良信息关键词记入用户兴趣点或者作为用户标签并据以推送信息内容，不得设置歧视性或者偏见性用户标签。

第十一条算法推荐服务提供者应当加强算法推荐服务版面页面生态管理，建立完善人工干预和用户自主选择机制，在首页首屏、热搜、精选、榜单类、弹窗等重点环节积极呈现符合主流价值导向的信息内容。

第十二条算法推荐服务提供者应当综合运用内容去重、打散干预等策略，并优化检索、排序、选择、推送、展示等规则的透明度和可解释性，避免对用户产生不良影响、引发争议纠纷。

第十三条算法推荐服务提供者不得利用算法虚假注册账号、非法交易账号、操纵用户账号，或者虚假点赞、评论、转发、网页导航等，实施流量造假、流量劫持；不得利用算法屏蔽信息、过度推荐、操纵榜单或者检索结果排序、控制热搜或者精选等干预信息呈现，实施自我优待、不正当竞争、影响网络舆论或者规避监管。

第十四条算法推荐服务提供者应当以显著方式告知用户其提供算法推荐服务的情况，并以适当方式公示算法推荐服务的基本原理、目的意图、运行机制等。

第十五条算法推荐服务提供者应当向用户提供不针对其个人特征的选项，或者向用户提供便捷的关闭算法推荐服务的选项。用户选择关闭算法推荐服务的，算法推荐服务提供者应当立即停止提供相关服务。

算法推荐服务提供者应当向用户提供选择、修改或者删除用于算法推荐服务的用户标签的功能。

用户认为算法推荐服务提供者应用算法对其权益造成重大影响的，有权要求算法推荐服务提供者予以说明并采取相应改进或者补救措施。

第十六条算法推荐服务提供者向未成年人提供服务的，应当依法履行未成年人网络保护义务，并通过开发适合未成年人使用的模式、提供适合未成年人特点的服务等方式，便利未成年人获取有益身心健康的信息内容。

算法推荐服务提供者不得向未成年人用户推送可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好等可能影响未成年人身心健康的信息内容，不得利用算法推荐服务诱导未成年人沉迷网络。

第十七条算法推荐服务提供者向劳动者提供工作调度服务的，应当建立完善平台订单分配、报酬构成及支付、工作时间、奖惩等相关算法，履行劳动者权益保障义务。

第十八条算法推荐服务提供者向消费者销售商品或者提供服务的，应当保护消费者合法权益，不得根据消费者的偏好、交易习惯等特征，利用算法在交易价格等交易条件上实行不合理的差别待遇等违法行为。

第十九条国家网信部门建立分类分级管理制度，根据算法推荐服务的舆论属性或者社会动员能力、内容类别、用户规模、算法推荐技术处理的数据敏感程度、对用户行为的干预程度等对算法推荐服务提供者实施分类分级管理。

第二十条具有舆论属性或者社会动员能力的算法推荐服务提供者应当在提供服务之日起十个工作日内通过互联网信息服务算法备案系统填报服务提供者的名称、服务形式、应用领域、算法类型、算法自评估报告、拟公示内容等信息，履行备案手续。　　

算法推荐服务提供者的备案信息发生变更时，应当在变更之日起五个工作日内办理变更手续。

算法推荐服务提供者终止服务的，应当在终止服务三十个工作日前办理注销备案手续，并作出妥善安排。

第二十一条国家和省、自治区、直辖市网信部门收到备案人提交的备案材料后，材料齐全的，应当在三十个工作日内予以备案，发放备案编号并进行公示；材料不齐全的，不予备案，并应当在三十个工作日内通知备案人并说明理由。

第二十二条完成备案的算法推荐服务提供者应当在其对外提供服务的网站、应用程序等显著位置标明其备案编号并提供公示信息链接。

第二十三条具有舆论属性或者社会动员能力的算法推荐服务提供者应当按照国家有关规定开展安全评估。　　

算法推荐服务提供者应当完善算法推荐服务管理机制，对算法推荐服务日志等信息进行留存，留存期限不少于六个月，并在相关执法部门依法查询时予以提供。　　

第二十四 条国家和省、自治区、直辖市网信部门会同有关主管部门对算法推荐服务开展算法安全评估和监督检查工作，对发现的问题及时提出整改意见并限期整改。　　

算法推荐服务提供者应当配合有关主管部门依法实施的安全评估和监督检查工作，并提供必要的技术、数据等支持和协助。　　

第二十五条参与算法推荐服务安全评估和监督检查的相关机构和人员应当对在履行职责中知悉的个人信息、隐私和商业秘密严格保密，不得泄露、出售或者非法向他人提供。　　

第二十六条算法推荐服务提供者应当接受社会监督，设置便捷的投诉举报入口，及时受理和处理公众投诉举报。　　

算法推荐服务提供者应当建立用户申诉渠道和制度，规范处理用户申诉并及时反馈，切实保障用户合法权益。　　

第二十七 条算法推荐服务提供者违反本规定第七条、第八条、第九条第一款、第十条、第十一条、第十二条、第十三条、第十四条、第十五条第二款、第二十二条、第二十六条规定的，由国家和省、自治区、直辖市网信部门依据职责给予警告、通报批评，责令限期改正；拒不改正或者情节严重的，责令暂停信息更新，并处五千元以上三万元以下罚款。构成违反治安管理行为的，依法给予治安管理处罚；构成犯罪的，依法追究刑事责任。

第二十八条算法推荐服务提供者违反本规定第六条、第九条第二款、第十五条第一款、第三款、第十六条、第十七条、第十八条、第二十三条、第二十四条第二款规定的，由网信等有关主管部门依据职责，按照有关法律、行政法规和部门规章的规定予以处理。　

第二十九条具有舆论属性或者社会动员能力的算法推荐服务提供者违反本规定第二十条的规定，未按照要求备案或者在报送备案时隐瞒有关情况、提供虚假材料或者通过欺骗、贿赂等不正当手段取得备案的，由国家和省、自治区、直辖市网信部门依法撤销备案，并给予警告、通报批评，责令限期改正；拒不改正或者情节严重的，责令暂停信息更新，并处五千元以上三万元以下罚款。　　

具有舆论属性或者社会动员能力的算法推荐服务提供者终止服务未按照要求及时办理注销备案手续，或者发生严重违法情形受到吊销互联网信息服务许可、关闭网站、终止服务等行政处罚的，由国家和省、自治区、直辖市网信部门予以注销备案。　　

第三十条本规定自2021年月日起施行。

个人信息保护法将于 11 月 1 日施行

Fri, 20 Aug 2021 20:26:11 CST

全国人大常委会周五通过了《个人信息保护法》，将于 11 月 1 日起施行。《个人信息保护法》（草案）的正式版全文还没有公布，中新网报道称，“任何组织、个人不得非法收集、使用、加工、传输他人个人信息，不得非法买卖、提供或者公开他人个人信息”，“个人信息处理者利用个人信息进行自动化决策，不得对个人在交易价格等交易条件上实行不合理的差别待遇”...根据草案，“关键信息基础设施运营者和处理个人信息达到国家网信部门规定数量的个人信息处理者，应当将在中华人民共和国境内收集和产生的个人信息存储在境内。确需向境外提供的，应当通过国家网信部门组织的安全评估”...

《关键信息基础设施安全保护条例》9 月 1 日生效

Thu, 19 Aug 2021 11:57:20 CST

给各位提个醒：

第三十一条未经国家网信部门、国务院公安部门批准或者保护工作部门、运营者授权，任何个人和组织不得对关键信息基础设施实施漏洞探测、渗透性测试等可能影响或者危害关键信息基础设施安全的活动。对基础电信网络实施漏洞探测、渗透性测试等活动，应当事先向国务院电信主管部门报告。

违反本条例第五条第二款和第三十一条规定，受到治安管理处罚的人员，5 年内不得从事网络安全管理和网络运营关键岗位的工作；受到刑事处罚的人员，终身不得从事网络安全管理和网络运营关键岗位的工作。

Feign 透明转发Header头信息的解决方案 - SegmentFault 思否

Mon, 21 Jun 2021 09:30:29 CST

问题

在 Spring Cloud 中微服务之间的调用会用到Feign，但是在默认情况下，Feign 调用远程服务存在Header请求头丢失问题。

解决方案

首先需要写一个 Feign请求拦截器，通过实现RequestInterceptor接口,完成对所有的Feign请求,传递请求头和请求参数。

Feign 请求拦截器

    public class FeignBasicAuthRequestInterceptor implements RequestInterceptor {

    private static final Logger logger = LoggerFactory.getLogger(FeignBasicAuthRequestInterceptor.class);

    @Override
    public void apply(RequestTemplate requestTemplate) {
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder
                .getRequestAttributes();
        HttpServletRequest request = attributes.getRequest();
        Enumeration<String> headerNames = request.getHeaderNames();
        if (headerNames != null) {
            while (headerNames.hasMoreElements()) {
                String name = headerNames.nextElement();
                String values = request.getHeader(name);
                requestTemplate.header(name, values);
            }
        }
        Enumeration<String> bodyNames = request.getParameterNames();
        StringBuffer body =new StringBuffer();
        if (bodyNames != null) {
            while (bodyNames.hasMoreElements()) {
                String name = bodyNames.nextElement();
                String values = request.getParameter(name);
                body.append(name).append("=").append(values).append("&");
            }
        }
        if(body.length()!=0) {
            body.deleteCharAt(body.length()-1);
            requestTemplate.body(body.toString());
            logger.info("feign interceptor body:{}",body.toString());
        }
    }
}

通过配置文件配置让所有 FeignClient，来使用 FeignBasicAuthRequestInterceptor

    feign:
  client:
    config:
      default:
        connectTimeout: 5000
        readTimeout: 5000
        loggerLevel: basic
        requestInterceptors: com.leparts.config.FeignBasicAuthRequestInterceptor

也可以配置让某个 FeignClient来使用这个 FeignBasicAuthRequestInterceptor

    feign:
  client:
    config:
      xxxx: # 远程服务名
        connectTimeout: 5000
        readTimeout: 5000
        loggerLevel: basic
        requestInterceptors: com.leparts.config.FeignBasicAuthRequestInterceptor

经过测试，上面的解决方案可以正常的使用；但是出现了新的问题。

在转发Feign的请求头的时候, 如果开启了Hystrix, Hystrix的默认隔离策略是Thread(线程隔离策略), 因此转发拦截器内是无法获取到请求的请求头信息的。

可以修改默认隔离策略为信号量模式：

    hystrix.command.default.execution.isolation.strategy=SEMAPHORE

但信号量模式不是官方推荐的隔离策略;另一个解决方法就是自定义Hystrix的隔离策略。

自定义策略

HystrixConcurrencyStrategy 是提供给开发者去自定义hystrix内部线程池及其队列，还提供了包装callable的方法，以及传递上下文变量的方法。所以可以继承了HystrixConcurrencyStrategy，用来实现了自己的并发策略。

    @Component
public class FeignHystrixConcurrencyStrategy extends HystrixConcurrencyStrategy {

    private static final Logger log = LoggerFactory.getLogger(FeignHystrixConcurrencyStrategy.class);

    private HystrixConcurrencyStrategy delegate;

    public FeignHystrixConcurrencyStrategy() {
        try {
            this.delegate = HystrixPlugins.getInstance().getConcurrencyStrategy();
            if (this.delegate instanceof FeignHystrixConcurrencyStrategy) {
                // Welcome to singleton hell...
                return;
            }

            HystrixCommandExecutionHook commandExecutionHook =
                    HystrixPlugins.getInstance().getCommandExecutionHook();

            HystrixEventNotifier eventNotifier = HystrixPlugins.getInstance().getEventNotifier();
            HystrixMetricsPublisher metricsPublisher = HystrixPlugins.getInstance().getMetricsPublisher();
            HystrixPropertiesStrategy propertiesStrategy =
                    HystrixPlugins.getInstance().getPropertiesStrategy();
            this.logCurrentStateOfHystrixPlugins(eventNotifier, metricsPublisher, propertiesStrategy);

            HystrixPlugins.reset();
            HystrixPlugins instance = HystrixPlugins.getInstance();
            instance.registerConcurrencyStrategy(this);
            instance.registerCommandExecutionHook(commandExecutionHook);
            instance.registerEventNotifier(eventNotifier);
            instance.registerMetricsPublisher(metricsPublisher);
            instance.registerPropertiesStrategy(propertiesStrategy);
        } catch (Exception e) {
            log.error("Failed to register Sleuth Hystrix Concurrency Strategy", e);
        }
    }

    private void logCurrentStateOfHystrixPlugins(HystrixEventNotifier eventNotifier,
                                                 HystrixMetricsPublisher metricsPublisher,
                                                 HystrixPropertiesStrategy propertiesStrategy) {
        if (log.isDebugEnabled()) {
            log.debug("Current Hystrix plugins configuration is [" + "concurrencyStrategy ["
                    + this.delegate + "]," + "eventNotifier [" + eventNotifier + "]," + "metricPublisher ["
                    + metricsPublisher + "]," + "propertiesStrategy [" + propertiesStrategy + "]," + "]");
            log.debug("Registering Sleuth Hystrix Concurrency Strategy.");
        }
    }

    @Override
    public <T> Callable<T> wrapCallable(Callable<T> callable) {
        RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
        return new WrappedCallable<>(callable, requestAttributes);
    }

    @Override
    public ThreadPoolExecutor getThreadPool(HystrixThreadPoolKey threadPoolKey,
                                            HystrixProperty<Integer> corePoolSize,
                                            HystrixProperty<Integer> maximumPoolSize,
                                            HystrixProperty<Integer> keepAliveTime,
                                            TimeUnit unit, BlockingQueue<Runnable> workQueue) {
        return this.delegate.getThreadPool(threadPoolKey, corePoolSize, maximumPoolSize, keepAliveTime,
                unit, workQueue);
    }

    @Override
    public ThreadPoolExecutor getThreadPool(HystrixThreadPoolKey threadPoolKey,
                                            HystrixThreadPoolProperties threadPoolProperties) {
        return this.delegate.getThreadPool(threadPoolKey, threadPoolProperties);
    }

    @Override
    public BlockingQueue<Runnable> getBlockingQueue(int maxQueueSize) {
        return this.delegate.getBlockingQueue(maxQueueSize);
    }

    @Override
    public <T> HystrixRequestVariable<T> getRequestVariable(HystrixRequestVariableLifecycle<T> rv) {
        return this.delegate.getRequestVariable(rv);
    }

    static class WrappedCallable<T> implements Callable<T> {
        private final Callable<T> target;
        private final RequestAttributes requestAttributes;

        WrappedCallable(Callable<T> target, RequestAttributes requestAttributes) {
            this.target = target;
            this.requestAttributes = requestAttributes;
        }

        @Override
        public T call() throws Exception {
            try {
                RequestContextHolder.setRequestAttributes(requestAttributes);
                return target.call();
            } finally {
                RequestContextHolder.resetRequestAttributes();
            }
        }
    }
}

致此，Feign调用丢失请求头的问题就解决的了。

参考

https://blog.csdn.net/zl1zl2z...
https://cloud.spring.io/sprin...

关注我

Oracle 统计信息收集 - Leohahah - 博客园

Tue, 08 Jun 2021 08:54:32 CST

官网网址参考：

https://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_stats.htm#CIHBIEII

https://docs.oracle.com/cd/B12037_01/server.101/b10759/statements_4005.htm#i2150533

https://asktom.oracle.com/pls/asktom/f?p=100:11:::::p11_question_id:5792247321358

https://docs.oracle.com/database/121/TGSQL/tgsql_histo.htm#TGSQL366

查询表上一次收集统计信息的时间：

1	`select` `owner,table_name,last_analyzed` `from` `dba_tables` `where` `owner=` `'SCOTT'` `;`

统计信息涉及的视图：

Column statistics appear in the data dictionary views USER_TAB_COLUMNS, ALL_TAB_COLUMNS, and DBA_TAB_COLUMNS. Histograms appear in the data dictionary views USER_TAB_HISTOGRAMS, DBA_TAB_HISTOGRAMS, and ALL_TAB_HISTOGRAMS; USER_PART_HISTOGRAMS, DBA_PART_HISTOGRAMS, and ALL_PART_HISTOGRAMS; and USER_SUBPART_HISTOGRAMS, DBA_SUBPART_HISTOGRAMS, and ALL_SUBPART_HISTOGRAMS.

收集统计信息主要有2种方法：

1. analyze

analyze可以用来收集表，索引，列以及系统的统计信息和直方图，以下为一些典型用法：

analyze table scott.emp compute statistics ; --收集所有的统计信息和直方图信息，包括表、列、索引。

analyze table scott.emp compute statistics for table ; --收集emp表的统计信息，不含列、索引统计信息和直方图。

analyze table scott.emp compute statistics for all columns;

--收集所有列的统计信息和直方图（超大表较耗资源，因为只要列中有非空值，那么就会收集这个列的统计信息和直方图）。

analyze table scott.emp compute statistics for all indexed columns; --收集所有索引列的统计信息和直方图。

analyze table scott.emp compute statistics for all indexes; --收集所有索引统计信息，不含列的统计信息和直方图。

analyze table scott.emp compute statistics for columns 列1,列2； --收集2个列的统计信息和直方图。

analyze index idx_ename delete statistics ; --删除索引idx_ename的统计信息。

analyze table scott.emp delete statistics ; --删除表t1所有的表，列，索引的统计信息和列直方图。

analyze table scott.emp estimate statistics sample 15 percent for table ;

--收集emp表的统计信息，以估算模式采样比例为15%进行收集，不含列、索引统计信息和直方图。

从语法可以看出，只有指定列统计信息收集时，才会收集相关列的直方图，此外收集直方图时for子句还可以加size子句，size的取值范围是1-254，默认值是75，表示直方图的buckets的最大数目。而dbms_stats包的size选择则有：数字|auto|repeat|skewonly选项，但analyze的size只能是数字。

关于直方图：

A histogram is a special type of column statistic that provides more detailed information about the data distribution in a table column. A histogram sorts values into "buckets," as you might sort coins into buckets.

从官网解释（参考第四个网址）来看，直方图就是一种特殊的列统计信息，这也与我们上边的推断相符，只有列才有直方图。

这里贴一个Tom Kyte用于查看analyze后统计信息的SQL：(已稍作改进，仅示例，这种格式的SQL不推荐，原SQL较简单参考第三个网址)

select t.num_rows as num_rows_in_table, i.index_name, i.num_rows as num_rows_in_index, co.num_analyzed_cols,ch.histogram_cnt

from ( select num_rows from user_tables where table_name = 'EMP' ) t,

( select index_name,num_rows from user_indexes where table_name = 'EMP' ) i,

( select count (*) as num_analyzed_cols from user_tab_columns where table_name= 'EMP' and num_distinct is not null ) co,

( select count ( distinct column_name) histogram_cnt from user_tab_histograms where table_name = 'EMP' ) ch;

需要注意的一点是for table选项在某些版本中并不只收集表统计信息，而是连列和索引的统计信息一块收集了，至于具体哪些版本的表现不同这里不做深究，使用上述SQL可以轻易的测试出你的analyze和dbms_stats语句到底收集了什么统计信息和直方图。

2. 调用dbms_stats包

dbms_stats与analyze的区别是：

analyze收集系统内部对象会报错，而dbms_stats不会

analyze不能正确的收集分区表的统计信息，而dbms_stats可以通过指定粒度来实现（granularity）。

analyze不能并行的收集统计信息，而dbms_stats可以（可以加上degree=>4来实现并行度为4的收集）。

Oracle推荐使用dbms_stats来收集统计信息，analyze将会被逐渐抛弃。

dbms_stats中负责收集统计信息的是以下几个存储过程：

GATHER_DATABASE_STATS

--This procedure gathers statistics for all objects in the database.

GATHER_DICTIONARY_STATS

--This procedure gathers statistics for dictionary schemas 'SYS', 'SYSTEM' and schemas of RDBMS components.

GATHER_FIXED_OBJECTS_STATS

--This procedure gathers statistics for all fixed objects (dynamic performance tables).

GATHER_INDEX_STATS

--This procedure gathers index statistics. It attempts to parallelize as much of the work as possible. Restrictions are described in the individual parameters. This operation will not parallelize with certain types of indexes, including cluster indexes, domain indexes, and bitmap join indexes. The granularity and no_invalidate arguments are not relevant to these types of indexes.

GATHER_SCHEMA_STATS

--This procedure gathers statistics for all objects in a schema.

GATHER_SYSTEM_STATS

--This procedure gathers system statistics.

GATHER_TABLE_STATS

--This procedure gathers table and column (and index) statistics. It attempts to parallelize as much of the work as possible, but there are some restrictions as described in the individual parameters.

三个常用Procedure用法详解：GATHER_SCHEMA_STATS（两种用法）、GATHER_TABLE_STATS、GATHER_INDEX_STATS

PROCEDURE GATHER_SCHEMA_STATS

Argument Name Type In / Out Default ?

------------------------------ ----------------------- ------ --------

OWNNAME VARCHAR2 IN

ESTIMATE_PERCENT NUMBER IN DEFAULT

BLOCK_SAMPLE BOOLEAN IN DEFAULT

METHOD_OPT VARCHAR2 IN DEFAULT

DEGREE NUMBER IN DEFAULT

GRANULARITY VARCHAR2 IN DEFAULT

CASCADE BOOLEAN IN DEFAULT

STATTAB VARCHAR2 IN DEFAULT

STATID VARCHAR2 IN DEFAULT

OPTIONS VARCHAR2 IN DEFAULT

OBJLIST OBJECTTAB OUT

STATOWN VARCHAR2 IN DEFAULT

NO_INVALIDATE BOOLEAN IN DEFAULT

GATHER_TEMP BOOLEAN IN DEFAULT

GATHER_FIXED BOOLEAN IN DEFAULT

STATTYPE VARCHAR2 IN DEFAULT

FORCE BOOLEAN IN DEFAULT

OBJ_FILTER_LIST OBJECTTAB IN DEFAULT

PROCEDURE GATHER_SCHEMA_STATS

Argument Name Type In / Out Default ?

------------------------------ ----------------------- ------ --------

OWNNAME VARCHAR2 IN

ESTIMATE_PERCENT NUMBER IN DEFAULT

BLOCK_SAMPLE BOOLEAN IN DEFAULT

METHOD_OPT VARCHAR2 IN DEFAULT

DEGREE NUMBER IN DEFAULT

GRANULARITY VARCHAR2 IN DEFAULT

CASCADE BOOLEAN IN DEFAULT

STATTAB VARCHAR2 IN DEFAULT

STATID VARCHAR2 IN DEFAULT

OPTIONS VARCHAR2 IN DEFAULT

STATOWN VARCHAR2 IN DEFAULT

NO_INVALIDATE BOOLEAN IN DEFAULT

GATHER_TEMP BOOLEAN IN DEFAULT

GATHER_FIXED BOOLEAN IN DEFAULT

STATTYPE VARCHAR2 IN DEFAULT

FORCE BOOLEAN IN DEFAULT

OBJ_FILTER_LIST OBJECTTAB IN DEFAULT

PROCEDURE GATHER_TABLE_STATS

Argument Name Type In / Out Default ?

------------------------------ ----------------------- ------ --------

OWNNAME VARCHAR2 IN

TABNAME VARCHAR2 IN

PARTNAME VARCHAR2 IN DEFAULT

ESTIMATE_PERCENT NUMBER IN DEFAULT

BLOCK_SAMPLE BOOLEAN IN DEFAULT

METHOD_OPT VARCHAR2 IN DEFAULT

DEGREE NUMBER IN DEFAULT

GRANULARITY VARCHAR2 IN DEFAULT

CASCADE BOOLEAN IN DEFAULT

STATTAB VARCHAR2 IN DEFAULT

STATID VARCHAR2 IN DEFAULT

STATOWN VARCHAR2 IN DEFAULT

NO_INVALIDATE BOOLEAN IN DEFAULT

STATTYPE VARCHAR2 IN DEFAULT

FORCE BOOLEAN IN DEFAULT

PROCEDURE GATHER_INDEX_STATS

Argument Name Type In / Out Default ?

------------------------------ ----------------------- ------ --------

OWNNAME VARCHAR2 IN

INDNAME VARCHAR2 IN

PARTNAME VARCHAR2 IN DEFAULT

ESTIMATE_PERCENT NUMBER IN DEFAULT

STATTAB VARCHAR2 IN DEFAULT

STATID VARCHAR2 IN DEFAULT

STATOWN VARCHAR2 IN DEFAULT

DEGREE NUMBER IN DEFAULT

GRANULARITY VARCHAR2 IN DEFAULT

NO_INVALIDATE BOOLEAN IN DEFAULT

STATTYPE VARCHAR2 IN DEFAULT

FORCE BOOLEAN IN DEFAULT

GATHER_SCHEMA_STATS参数详解：（其他存储过程的参数解释参见官方页面，很多参数description都是通用的）

详见： Table 103-30 GATHER_SCHEMA_STATS Procedure Parameters

一些实际用例：

EXEC DBMS_STATS.GATHER_SCHEMA_STATS( 'SCOTT' ,estimate_percent=>80,method_opt=> 'FOR ALL COLUMNS SIZE AUTO' ,degree=>4, cascade => TRUE );

EXEC DBMS_STATS.GATHER_TABLE_STATS( 'SCOTT' , 'EMP' ,estimate_percent=>80,method_opt=> 'FOR ALL COLUMNS SIZE AUTO' ,degree=>4, cascade => TRUE );

EXEC DBMS_STATS.GATHER_INDEX_STATS( 'SCOTT' , 'PK_EMP' ,estimate_percent=>80,degree=>4);

一些特别提示：

虽然method_opt的description中并未提及for table这个选项，但其实这个选项也是有效的，同analyze一样，这个参数在不同版本的表现也是不一样的，具体差异也可以轻易的使用本文中提供的SQL观察到。
如果想使用compute方式收集统计信息，将estimate_percent设为100或者null即可。
Oracle有auto optimizer stats collection的自动维护任务定期的收集统计信息，这些任务是默认开启的，但当数据库变的很大之后就会引发严重的性能问题，建议只保留周末的一个窗口，其他窗口全部关闭。
直方图统计信息并不是那么的重要，只有在遇到对倾斜列（skew）的查询很频繁时才有用，这种情况并不常见。
不再推荐使用analyze来收集统计信息，除非是做测试或者表很小，dbms_stats的并行度选项能加快收集速度。
对大表采样收集统计信息时一般采样比例不需要很大，通常10%到30%即可，如果业务可以提供维护窗口，那100%也没什么大不了。
如果要详细了解统计信息收集了什么内容，可以参考本文提供的网址链接和视图。

关于执行权限：

To invoke this procedure you must be owner of the table, or you need the ANALYZE ANY privilege. For objects owned by SYS, you need to be either the owner of the table, or you need the ANALYZE ANY DICTIONARY privilege or the SYSDBA privilege.

当然关于权限还有个取巧的办法，示例如下：

conn hr/hr

create or replace procedure gather_stats is

begin

dbms_stats.gather_table_stats( 'HR' , 'EMPLOYEES' );

end gather_stats;

/

grant select on hr.employees to scott;

grant execute on gather_stats to scott;

conn scott/scott exec hr.gather_stats;

Oracle里收集与查看统计信息的方法_DBA Fighting!的技术博客_51CTO博客

Tue, 08 Jun 2021 08:51:05 CST

Oracle数据库里的统计信息是这样的一组数据：它存储在数据字典里，且从多个维度描述了Oracle数据库里对象的详细信息。CBO会利用这些统计信息来计算目标SQL各种可能的、不同的执行路径的成本，并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划。

Oracle数据库里的统计信息可以分为如下6种类型：

表的统计信息
索引的统计信息
列的统计信息
系统统计信息
数据字典统计信息
内部对象统计信息

表的统计信息用于描述Oracle数据库里表的详细信息，它包含了一些典型的维度，如记录数、表块(表里的数据块)数量、平均行长度等。

索引的统计信息于描述Oracle数据库里索引的详细信息，它包含了一些典型的维度，如索引的层级、叶子块的数量、聚簇因子等。

列的统计信息于描述Oracle数据库里列的详细信息，它包含了一些典型的维度，如列的distinct值的数量、列的NULL值的数量、列的最小值、列的最大值以及直方图等。

系统统计信息于描述Oracle数据库所在的数据库服务器的系统处理能力，它包含了CPU和I/O这两个维度，借助于系统统计信息，Oracle可以更清楚地知道目标数据库服务器的实际处理能力。

数据字典统计信息用于热核Oracle数据库里数据字典基表(如TAB$、IND$等)、数据字典基表上的索引，以及这些数据字典的列的详细信息，描述上述数据字典基表的统计信息与描述普通表、索引、列的统计信息没有本质区别。

内部对象统计信息用于描述Oracle数据库里的一些内部表(如X$系列表)的详细信息，它的维度和普通表的统计信息的维度类似，只不过其表块的数量为0，因为X$系统表实际上只是Oracle自定义的内存结构，并不占用实际的物理存储空间。

1、收集统计信息

在Oracle数据库里，通常有两种方法可以用来收集统计信息：一种是使用ANALYZE命令；另一种是使用DBMS_STATS包。表、索引、列的统计信息和数据字典统计信息用ANALYZE命令或者DBMS_STATS包收集均可，但系统统计信息和系统内部对象统计信息只能使用DBMS_STATS包来收集。

对系统内部表若使用ANALYZE命令来收集统计信息，会报错ORA-02030

1.1用ANALYZE命令收集统计信息

从Oracle7开始，ANALYZE命令就可以用来收集表、索引、列的统计信息，以及系统统计信息。

典型用法如下：

zx@ORCL>create table t2 as select * from dba_objects;

Table created.

zx@ORCL>create index idx_t2 on t2(object_id);

Index created.

zx@ORCL>analyze index idx_t2 delete statistics;

Index analyzed.

从Oracle 10g开始，创建索引后Oracle会怎么收集目标索引的统计信息，出现演示的目的，这里删除索引IDX_T2的统计信息：

执行sosi脚本，从输出内容可以看到表T2、表T2的列和索引IDX_T2均没有相关的统计信息

zx@ORCL>select count(*) from t2;

  COUNT(*)
----------
     86852

只对表T2收集统计信息，并且以估算模式，采样的比例为15%：

zx@ORCL>analyze table t2 estimate statistics sample 15 percent for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是估算模式所以估算结果和实际结果并不一定会完全匹配，比如表T2的实际数量与估算出的数量不一致。

只对表T2收集统计信息，并且以计算模式：

zx@ORCL>analyze table t2 compute statistics for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在对表T2的列OBJECT_NAME和OBJECT_ID以计算模式收集统计信息：

zx@ORCL>analyze table t2 compute statistics for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看出，现在列OBJECT_NAME和OBJECT_ID确实已经有统计信息了

注：在崔华老师的《基于Oracle的SQL优化》一书中提到T2原有的统计信息已经被抹掉了，也就是说对同一个对象而言，新执行的ANALYZE命令会抹掉之前ANALYZE的结果。但是在我实际的执行结果是表T2原有的统计信息没有被抹掉。我用到的环境是10.2.0.4和11.2.0.4，暂时没有11.2.0.1的环境。

可以使用如下的命令同时以计算模式对表T2和列OBJECT_NAME、OBJECT_ID收集统计信息：

zx@ORCL>analyze table t2 compute statistics for table for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看到表T2和列OBJECT_NAME、OBJECT_ID上都有统计信息了。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>analyze index idx_t2 compute statistics;

Index analyzed.

再次执行sosi脚本，从输出可以看到，现在索引IDX_T2已经有了统计信息，并且之前收集的表T2和列OBJECT_NAME、OBJECT_ID上的统计信息并没有被抹掉，这是因为我们刚才执行的ANALYZE命令和之前执行的ANALYZE命令针对的不是同一个对象。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>analyze table t2 delete statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，刚才收集的表T2、表T2的列OBJECT_NAME、OBJECT_ID以及索引IDX_T2的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列和表T2上的所有索引的统计信息，执行如下的语句就可以了：

zx@ORCL>analyze table t2 compute statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，现在表T2、表T2的所有列和索引IDX_T2的统计信息都有了。

1.2用DBMS_STATS包收集统计信息

从Oracle 8.1.5开始，DBMS_STATS包被广泛用于统计信息的收集，用DMBS_STATS包收集统计信息也是Oracle官方推荐的方式。在收集CBO所需要的统计信息方面，可以简单的将DBMS_STATS包理解成是ANALYZE命令的增加版。

DBMS_STATS包里最常用的就是如下4个存储过程：

GATHER_TABLE_STATS：用于收集目标表、目标表的列和目标表上的索引的统计信息。
GATHER_INDEX_STATS：用于收集指定索引的统计信息。
GATHER_SCHEMA_STATS：用于收集指定schema下所有对象的统计信息。
GATHER_DATABASE_STATS：用于收集全库所有对象的统计信息。

现在介绍DBMS_STATS包在收集统计信息时的常见用法，还是针对上面的测试表T2，这里使用DBMS_STATS包实现了和ANALYZE命令一模一样的效果。

先删除表T2上的所有统计信息

analyze table t2 delete statistics;

只对表T2收集统计信息，并且以估算模式，采用的比例同样为15%：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>15,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的估算模式，所以估算结果和实际结果并不一定会完全匹配。

需要注意的是，这里Oracle数据库的版本是11.2.0.4，我们在调用DMBS_STATS.GATHER_TABLE_STATS时指定参数METHOD_OPT的值为'FOR TABLE',这表示只收集表T2的统计信息。这种收集表统计信息的方法并不适用于Oracle数据库所有的版本。例如这种方法就不适用于Oracle10.2.0.4和Oracle10.2.0.5，在这两个版本里，即使指定了'FOR TABLE'，Oracle除了收集表统计信息之外还会对所有的列收集统计信息。

如果公对表T2收集统计信息，并且是以计算模式收集，用DBMS_STATS包实现的方法就是将估算模式的采样比例(即参数ESTIMATE_PERCENT)设置为100%或NULL；

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>NULL,method_opt=>'FOR TABLE',cascade=>false);

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2的统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在我们来对表T2的列OBJECT_NAME、OBJECT_ID以计算模式收集统计信息(不收集直方图)：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'for columns size 1 object_name,object_id',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在表T2的列OBJECT_NAME、OBJECT_ID上都有统计信息了，并且Oracle还会同时收集表T2上的统计信息(注意，这和ANALYZE命令有所区别)。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>exec dbms_stats.gather_index_stats(ownname=>'ZX',indname=>'IDX_T2',estimate_percent=>100);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在索引IDX_T2已经有了统计信息。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>exec dbms_stats.delete_table_stats(ownname=>'ZX',tabname=>'T2');

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，表T2、表T2的所有列及表T2的所有索引的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列及表T2的所有索引的统计信息，执行如下语句就可以了

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,cascade=>true);

PL/SQL procedure successfully completed.

1.3 ANALYZE和DBMS_STATS的区别

从上面的演示中可以看出ANALYZE命令和DBMS_STATS包都可以用来收集表、索引和列的统计信息，看起来它们在收集统计信息方面的效果是一模一样的，为什么Oracle会推荐使用DBMS_STATS包来收集统计信息呢？

因为ANALYZE命令和DMBS_STATS包相比，存在如下缺陷：

ANALYZE命令不能正确地收集分区表的统计信息，而DBMS_STATS包却可以。ANALYZE命令只会收集最低层次对象的统计信息，然后推导和汇总出高一级的统计信息，比如对于有子分区的分区表而言，它只会先收集子分区统计信息，然后再汇总，推导出分区或表级的统计信息。有的统计信息是可以从当前对象的下一级对象进行汇总后得到的，比如表的总行数，可以由各分区的行数相加得到。但有的统计信息则不能从下一级对象得到，比如列上的distinct值数量NUM_DISTINCT以及DESNSITY等。

ANALYZE命令不能并行收集统计信息，而DBMS_STATS包却可以。并行收集统计信息对数据量很大的表表而言，是非常有用的特性。对于数据量很大的表，如果不能并行收集统计信息，则意味着如果想精确地收集目标对象的统计信息，那么耗费的时间可能会非常长，这有可能是不能接受的。在Oracle数据库里，DBMS_STATS包收集统计信息可以并行执行，这在一定程度上缓解了对大表的统计信息收集过长所带来的一系列问题。

DBMS_STATS包的并行收集是通过手工指定输入参数DEGREE来实现的，比如对表T1进行收集统计信息，同时指定并行度为4：

exec dbms_stats.gahter_table_stats(ownname=>'SCOTT',tabname=>'T1',cascade=>true,estimate_percent=>100,degree=>4);

当然，DBMS_STATS包也不是完美的，它与ANALYZE命令相比，其缺陷在于DBMS_STATS包只能收集与CBO相关的统计信息，而与CBO无关的一些额外信息，比如行迁移/行链接的数量(CHAIN_CNT)、校验表和索引的结构信息等，DBMS_STATS包就无能为力了。而ANALYZE命令可以用来分析和收集上述额外的信息，比如analyze table xxx list chained rows intoyyy可以用来分析和收集行迁移/行链接的数量，analyzeindex xxx validate structure可以用来分析索引的结构。

2、查看统计信息

前面介绍了如何收集统计信息，那如何查看这些统计信息呢？Oracle数据库的统计信息会存储在数据字典里，我们只需要去查询相关的数据字典就好了。如果有充裕的时间，现写SQL去查询数据字典里的统计信息也没有什么，但当我们真正碰到有性能问题的SQL时，通常会希望能在第一时间就收集到与目标SQL相关的各种统计信息，以便于在第一时间定位问题所在，这时候写SQL去查询数据字典就已经来不及了，所以我们需要事先准备好通用的查询统计信息的脚本，出问题的时候只需要运行一下脚本，就能在第一时间获取目标对象的所有统计信息了。

sosi脚本(Show Optimizer Statistics Information)就是这样一种脚本，国内的Oracle数据库专家也一直在用这个脚本，它源于MOS上的文章：SCRIPT - Select to show OptimizerStatistics for CBO (文档ID 31412.1)，用法很简单，只需要运行一下sosi脚本，并指定要查看统计信息的表名就可以了。它支持分区表，显示分为三部分，分别是表级别的统计信息，分区级别的统计信息和子分区级别的统计信息。前面做实验用到的也是这个脚本。

附件是sosi脚本可以下载使用。

参考《基于Oracle的SQL优化》

抖音 360 百度等应用被指过多收集用户信息

Fri, 21 May 2021 16:35:24 CST

网信办公布了《关于抖音等105款App违法违规收集使用个人信息情况的通报》，称在调查之后发现这些应用收集了与其服务无关的个人信息或未经用户同意收集使用个人信息。被列入名单中的应用包括抖音、快手、360 浏览器、搜狗浏览器、百度浏览器、360 搜索、欧朋浏览器（Opera）、UC、傲游、领英、猎聘、前程无忧、智联、以及百度等等。网信办要求相关运营者在 15 个工作日内完成整改，逾期未完成整改将面临惩罚。

信息化系统迁移方案

Wed, 14 Apr 2021 10:20:04 CST

总述

按照本期招标采购要求，中心在建成后要实现对迁移应用和新建业务平台的一体化集成。
考虑到需要迁移的指挥中心现有应用包含了分析管理平台、指挥平台，上述平台都是中心的核心、重要应用，因此我公司认为原系统的搬迁将是项目建设的重点和难点。
本方案设计以我公司与用户现系统承建公司的初步技术交流、用户现状分析为基础，给出搬迁方案设计。

系统迁移需求分析

按照用户招标要求，本期系统迁移的具体需求分析如下。
中心原有应用系统将全部迁移至虚拟化服务平台，迁移期间必须保证工作不能中断，历史数据不能损失；迁移后的系统与多媒体融合通信指挥平台融合对接。
系统迁移的难点是系统切割时间节点的合理规划和确保电话接入路由的转换，历史数据的无损迁移也是系统搬迁的难点和重点。

中心系统迁移需求分析总体结论

通过对中心现有上述应用迁移的需求分析，鉴于原系统建设单位并非我公司，迁移过程中还存在对原建设厂商协调的工程风险。我公司认为系统迁移的重点内容包括：涉及运营商的接入切割，原有数据的迁移，合理切割时间节点规划。

迁移方案总体思路

中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移方案设计中，我们重点考虑几个问题。

保障业务中断停机时间最小化

业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可接受的。我们给予这样的要求，考虑到如何将停机时间最小，能否实现0停机的建设目标？
1、对于服务器操作系统而言，我们可以采用P2V的方式，利用操作系统的Volume Shadow Copy卷影副本复制服务作为基础，来实现在旧系统环境下的系统无修改，不停机的情况下，将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。
2、对于应用中间件和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点操作，这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。
3、对于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。

业务切割时间节点优化

针对×××系统等需要确保不间断对外提供服务的应用，需要通过对用户历史应用进行分析，选择最优的切割时间节点，并提切割期间的备份链路、人工受理手段。

迁移后完整性测试

迁移涉及到应用、实例、数据库的操作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。

服务器硬件环境迁移方案

按照用户招标要求，本次项目建设的服务硬件环境主要是从原有刀片服务器向本次招标新采购云服务平台的迁移。云服务平台支持对原有服务器硬件环境和操作系统环境虚拟，可以降低迁移的难度。

迁移评估

迁移前，我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派员勘察现有系统的架构和资源使用状况，评估过程必须包含以下信息和内容：

现有系统支撑的服务数量以及在服务器中的分布情况；
现有物理服务器资源占用状况，包括CPU、内存、磁盘和网络连接状况，为保证迁移成功，目标虚拟机规格应不低于原物理机标准；
当前的物理环境是否支持虚拟化，是否支持资源扩展，因为在迁移之前须在物理服务器上完成虚拟化；
对当前的存储容量和资源利用率进行评估，需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用，比如有些服务器是在本地磁盘上创建系统盘和用户盘，有些服务器则在本地磁盘上创建系统盘而在SAN/NAS上创建用户盘。

迁移计划

通过对现有网络环境的评估，我们对现有资源利用率，服务以及系统需求非常清晰并进行评估后才能开始对迁移进行计划，步骤如下：

确定迁移步骤，包括所有服务器的迁移先后顺序，其顺序按风险的高低降序排列。
确定备份方案，由于现有系统会被加固，某些服务器通过虚拟化重复利用，而在虚拟化前需要清除所有的数据，因此需要对这些服务器进行备份保证服务的连续性。
确定并准备好迁移所需的工具，包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。
在实际迁移开始之前确定额外的测试环境，该测试环境能够引导测试从而确保迁移成功。因此，测试环境需明确设计的服务器和存储数量。
规划网络环境，由于网络中的服务器各处不同位置，因此在迁移中需考虑到网络连接情况、数据备份方式，以及网络流量来源，确定网络流量是否会引发网络拥塞
确定迁移周期以及参与人员，包括迁移起止时间，团队能力建设以及团队成员的角色。

测试计划

迁移计划后，执行小批量的测试迁移方案，这里会涉及到首批迁移的测试和审核，步骤如下：

准备用于测试迁移的测试系统环境，在测试时，第一批服务器将会迁移到该系统环境中。
安装并核实迁移工具，此时要执行第一批服务器的P2V迁移。
对第一批服务器，需分析存储系统，不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS存储系统。

迁移测试

在第一批服务器和服务的小批量测试迁移后，需对迁移后的服务器进行测试，包括单元测试和性能测试。

迁移实施

在迁移实施过程中，所有的服务器都会被迁移到虚拟化系统下。执行步骤如下：

确保批量迁移的整个网络环境已准备完毕，并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。
对迁移系统进行性能审核和健康检查，如果系统状态监视则停用旧系统并将其服务暂时转移到新的虚拟化系统中。
进行利旧，对于一部分可用的旧硬件可在服务器虚拟化中重新再利用，一些软件资源需扩展，如内存和硬盘。这些服务器构成最终的虚拟化基础设施，即最终系统。
最后，在目标系统和最终系统之间进行V2V迁移。

服务器虚拟化前进行备份

为了对旧系统中的物理服务器进行虚拟化，需考虑服务器虚拟化带来的影响。例如，现有服务器的重复利用，服务器虚拟化时会对这些服务器的CPU，内存以及硬盘资源进行再利用，然而这些服务器上存在某些服务仍在运行，若无备份则会影响现有业务。因此，在执行迁移和虚拟化之前，必须先对需利旧的服务器进行备份。
提供物理备份服务器，并已进行虚拟化，数据和服务器已备份到虚拟化系统。

首先，对于要被迁移的服务器上，一般会存在多种服务正在运行，而且这些服务器在迁移评估后认为在虚拟化场景下可再利用的。但是，迁移过程中不允许存在较长的停机时间，因此需要准备一台采用虚拟化平台的备份虚拟机，通过P2V将该服务器备份到虚拟机上。
备份完所有需要进行虚拟化的服务器之后，这些服务器上安装虚拟化软件进行虚拟化，根据评估阶段确定的容量规划，在虚拟化平台上创建相应规格的虚拟机，其计算资源用于承接旧系统中的服务。
准备好所有的虚拟机后，规划和安装相关迁移工具，将备份系统中的服务迁移到虚拟化系统的虚拟机中。虚拟机迁移是指将备份的虚拟化系统中的应用服务迁移到最终的虚拟化系统中。
虚拟机迁移完毕后，要对这些服务进行测试，最后停用旧系统，所有服务切换到虚拟化系统中。

迁移的详细操作步骤

迁移的具体步骤及描述如下:

在评估阶段，虚拟化和迁移之前需收集的信息如下：
- 性能统计：包括CPU使用率，内存使用率，硬盘IOPS和硬盘使用情况；
- 物理服务器配置：包括CPU规格，内存容量，硬盘容量统计物理服务器部署位置，分析是否支持虚拟化，累计支持虚拟化的服务器数量，并规划出虚拟化中需新增的硬件情况；
- 通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。可采用信息收集工具。
分析现有服务的依赖条件，对当前系统进行备份。
- 确定应用系统对服务器的依赖关系，可作为迁移参考，确定所有服务器的迁移优先级顺序。
- 在确定各服务的依赖条件后，对需进行虚拟化的服务器进行备份。
容量规划和虚拟化执行
- 根据当前的资源使用和需求情况，计算虚拟化所需的容量。
规划应用服务
- 在拟化解决方案中，同类虚拟机部署在同一个计算资源池中，在同一个池中可相互共享存储/计算资源，一个集群的故障不会影响其他资源池。
虚拟化规划和虚拟机分配
- 建立虚拟化平台后，要准备最终的迁移资源。迁移前，如果服务器a具备双核CPU和2G内存，那么在虚拟化平台中就创建一个2核/2G内存的虚拟机，并分配相应的硬盘。
规划迁移工具
- 采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进行磁盘复制。
通过工具执行在线迁移
- 准备好源系统，目标虚拟机以及目标系统后，决定迁移时需使用的迁移工具和迁移策略。
迁移测试
- 迁移后，需进行测试来验证迁移是否成功，测试场景如下：应用服务迁移后对虚拟化基本功能的监测；
- 迁移前后应用服务的特性功能是否几乎相同；
- 虚拟化系统的性能监控；
- ….
停用旧系统
- 截至目前现有的服务器已经被虚拟化和重复使用，其他一些不支持虚拟化的服务器上对应的服务也已经迁移到虚拟化平台，那么现在可将应用服务切换到虚拟系统并停用旧系统。

运营商接入链路（路由）迁移

运营商接入链路（路由）的迁移主要是新中心所需物理链路的申请，电话号码接入路由制作、应用正式切割前测试号码的开通以及切割当日应急措施。针对前四部分内容，可以按照中心需要完全备份一份，在系统正式切割前进行模拟运行测试。
切割当日要做好应急保障措施，如切割一旦不成功，迅速切回原路由保障系统的运行。同时在新指挥备份足够的备份链路，支持人工受理。
上述链路的具体配置方案在中标后进一步确认。

应用系统和数据库迁移方案

针对本项目建设，我们将在应用系统和数据库迁移前，在用户新招标采购的云平台中部署与原应用一样的操作系统、中间件、服务器管理平台软件环境，确保迁移的环境变化风险最低。

应用服务器迁移

针对本项目应用系统迁移，原系统全部是基于Tomcat应用环境、Java应用程序框架。本方案计划对Tomcat等应用环境以及Java应用程序框架提出构建Tomcat环境的NLB群集，将当前系统不停机加入到NLB群集中，使之成为群集中的一个节点，而新环境则为另外一个节点。实施完成后再退出此迁移群集，将新环境加入到新的构建的NLB群集。 NLB不但能实现均衡负载，而且还能实现多种形式的冗余。NLB主要用于那些文件改动不大，并且不常驻内存的环境，比如WEB服务、FTP服务、和VPN服务等。当用户访问集群的时候，集群能将访问请求分摊到集群中的每个服务器上，以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中，每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB要求至少两个节点，其中一个节点不能使用，这全部负载将落入到剩下的那个节点上，即全载。NLB能提供三种冗余功能，软件冗余、硬件冗余、站点冗余。

数据库迁移实施

针对本项目数据库迁移，需要将中心积累的历史数据文件搬迁到新中心服务器，并且要求最小宕机时间，同时面临的难点还包括服务器并不在同一个一个机房。

分析与设计思路

针对本项目数据库搬迁环境特点：第一个是数据库文件比较大；第二是传送文件的速度可能会比较慢（广域网传输）。初步解决方案如下。
为了使宕机时间最短，我们这里使用完整备份和差异备份来迁移数据库，在白天的时候对需要迁移的数据库进行一次完整备份（XXX_full.bak），并把备份文件拷贝（这里可以使用FTP软件进行断点续传）到目标服务器进行还原，等到下班时间之后再进行一次差异备份（XXX_diff.bak），再把这个差异备份拷贝到目标服务器，在完整还原的基础上再进行差异还原。
这里的宕机时间 = 差异备份时间 + 传送差异备份文件时间 + 还原差异备份文件时间，不存在宕机时间。

保证数据迁移过程中的安全性和操作可审计性

数据迁移中的安全性不可忽略，本方案设计基于多重数据审计功能实现迁移安全性和操作审计性。

系统迁移的具体组织实施方案

针对本项目建设，涉及中心生产系统的搬迁，上述系统具有停机时间要求短、系统结构复杂、测试时间长、设备繁多、使用人员多、层次复杂等特点。本项目搬迁，时间非常紧,且设备间的稳定性也是一个考验。因此，必须协调好各单位人员的关系，齐心协力才可能在预定时间内完成搬迁工程。
本项目搬迁组织以尽量不影响日常工作或将影响降低到最低为前提的情况下制定，即在保障内容最少日的最少时间节点开始搬迁，尽快完成必须搬迁的服务器、网络设备的搬迁、安装及测试。并且在开机以后，继续跟踪系统的运行情况，随时处理系统运行的异常情况。搬迁需要原系统建设公司人员的充分协调及配合下才能完成本次搬迁任务。

搬迁规划

实施流程：

流程主要根据搬迁前的需要制定，主要详细了解当前系统设备情况，系统运行情况。针对所了解情况制定详细搬迁方案以及应急方案。
专业工程师了解用户现在机房的现状以及搬迁后的具体要求。充分考虑在实施过程中可能出现的各种情况，定制详细可行性的迁移实施计划，将机房迁移工作对用户的影响降至最小。
编制搬迁前及搬迁后的物理布置表、连接表、线缆号表。可根据用户情况分为多个系统进行分类。
在搬迁过程中需要XXX技术人员密切配合。
为保证搬迁工作顺利、有序、安全的进行将制定详细的搬迁流程，进行细致的分工，具体工作安排到人，责任到人。
搬迁工作中的每项工作原则最少安排 2 人，以保证工作的准确性。

详细实施方案

为了搬迁能按时顺利进行，并且在搬迁后能够保证设备正常运行，我们制定了一系列简单明了的工作表，帮助工程实施人员确定各种搬迁工作中要执行的工作是否完成。避免工作失误，避免造成搬迁工作的延误。
实施流程：目的机房的要求：
需要在搬迁前检查目的机房的必要设备设施是否符合要求，本工作表是保证搬迁后设备能否稳定正常运行的先决条件，在搬迁前由搬迁负责人同相关人员填写确认。

应急处理

在设备搬迁后出现异常情况时现场技术人员立即检查设备，检查故障现象，确定故障位置。
硬件故障在备件准备范围内的立即更换，不在范围内的立即使用备用设备，最短时间内启用备用设备。由于配置数据或系统不能启动的，立即使用系统光盘备份数据等先前准备的备用工具软件，系统软件重新按装或恢复。

震惊！手机恢复出厂设置数据仍可“复活”，一两毛钱就能获取你的基本信息！

Sun, 11 Apr 2021 16:53:00 CST

4月10日消息，据央视财经频道新闻报道，手机在恢复出厂设置后，仍然可以通过特殊手段来恢复数据。

就此新闻报道后，关于手机隐私泄露又再次引起了人们的担忧。

对此，在微博上有网友表示，“从来不卖旧手机，我宁愿放着”，“害怕第三方保留数据”，大家更愿意放着闲置，也不想承担数据泄露的风险。

不过可以理解的是，大部分人使用手机不会超过三到四年，就会考虑换新机。在换手机之前，大家都会进行清空和恢复出厂设置，结果这只是从表面上删除了数据，实际上，一些基本数据和重要信息是可以“复活”的！

怎么做到数据“复活”？

数据“复活”，对于技术人员来说是“零门槛”。

如今在各大电商平台上，搜索“恢复手机数据”，就会出现大量恢复数据的网店，这些网店都保证“价格不等，不能保证恢复多少数据，查完付钱”。

据报道了解，“进行手机数据恢复的人员，不论是在线下还是远程操作，都会使用名为 “取证系统”的终端设备”。

经过这种操作，原手机主人的基本信息如电话、聊天记录、账号密码等信息都可以获得。或许你会认为，我把重要信息保存在类似百度云的云端不就好了吗？

那也不行，因为恢复手机数据，同样可以获得你的账号密码信息，如果你在云端的登陆处于一种自动登录状态，你保存在云端的信息同样也可以被盗取。因为个人删除只是在手机文件上让它“消失”，只需要在芯片中找到一条通往存储完整数据区域的路径即可。

可以这样认为，对于技术人员来说，一般手机的存储芯片没有大的损坏，就可以恢复数据。

为什么会这样？

其实，大家选择的恢复出厂设置，实际上，是将设备或仪器的个性设置恢复到出厂的默认状态，如待机方式、开始界面、操作快捷键、定时提醒等等恢复到出厂时的设置但不会删除存储的数据。

手机芯片是电子设备中最重要的部分，承担着运算和存储的功能。有媒体解释，“尽管目前的手机采用的大都是 eMMC、UFS 闪存芯片，但其原理与电脑 SSD 类似，单纯的删除操作并不能抹掉文件”。

你的手机数据可以值多少钱？

你的数据能卖多少钱，和市场需求有关。

首先，我们看一下大家是怎么处理手机的，根据微博上环球网设置的投票，怎么处理自己的旧手机？将近两万人进行投票显示，有约7000人选择“留着当备用机”，有约5000人表示愿意“静静放着闲置”，还有约3000人选择“二手平台交易”。

从选项比例来看，大家更愿意把手机留在自己手上，会觉得更安全。还有不少人愿意进行二手交易，从安全角度来看，如果把手机留在手上，的确可以减少数据泄露的风险，是相对稳妥的做法，往往把手机进行二手交易的风险更大。

在2020年，因为疫情的影响，受手机产需供能的影响，华为、小米等著名手机品牌出现了需求下滑的情况。来自市场调研机构IDC发布的《2020-2024年全球二手智能手机预测》中显示，在2020年，全球二手智能手机的出货量达到2.254亿部。去年的全球智能手机三星品牌的出货量是2.66亿部，二手手机和全球出货量第一的三星手机数据相差不是很大。

二手手机的市场份额扩大，越来越多的人愿意接受二手手机。有些不法商家将二手手机经过处理，收集到的部分数据，然后打包出售就已经形成了一条完整的地下产业链。

手机的主人如果不能很好地清除数据，确实会有安全风险。

根据知情人士透露，“一般一毛一条信息”。在去年1月，中国电信超2亿条用户信息被卖案件审判书中提到，被告人以0.01元/条至0.2元/条的价格出售，累计获利2000余万元，涉及公民个人信息2亿余条。

所以，一毛钱就可以获得你的基本信息，通话记录、短信、联系人、多媒体文件、第三方支付信息、邮件信息等。

手机数据怎样才能安全清除？

你觉得只有变卖二手手机才会有风险吗？

你有过想恢复微信信息的时候吗？有过误删重要照片的时候吗？有过手误删掉重要联系人电话号码的时候吗？

在这样的情况下，你只是单纯的想恢复部分数据也有可能被第三方保留数据，所以，针对这类的手机数据恢复，大家需要尽量找安全的平台进行恢复，或者保留好重要信息，尽量避免第三方接触到你的重要信息，以免泄露。

既然手机芯片是关键，那应该可以物理摧毁吧？这个办法并不推荐，手机是比较精密的设备，进行暴力拆卸，自己会有一定的安全危险。并且经过拆卸再组装，这样的手机基本上不能再销往二手平台。

在这里有一个大家公认比较简单实用的方法。

首先，删除社交APP的登录设备，也要退出APP的原有账号，这两项不同的手机会有不同的操作，然后，再清除所有数据，把手机恢复出厂设置。

前面已经说过单纯的把手机恢复出场设置并不安全，所以，我们要在最后对手机进行“完全复写”。

完全复写是指用其他不重要的文件、视频、图片等来重新占据你的手机内存，并且要保证手机内存处于“完全占满”的状态。每复写一次，就需要再次进行格式化，重复复写5到8次是比较安全的，这个时候就可以把你的手机安全的卖掉了，就可以保护你的隐私安全。

目前在应用市场上有许多“全家桶”可以下载，根据自己的手机内存选择下载，达到基本占满就可以了，还不够，可以继续下载内存消耗大的文件。

同样的，重复几次，想要再次找回你的数据就比较难了。重复过后，自己需要再检查一下，也通过专业人士再尝试找回信息，看能不能找回自己的数据信息，如果没有，就说明成功了。

如今数据泄露问题随着网络技术的发展变得更为严重，如何在智能化的各种社会场景保证个人信息安全，还需要大家的共同努力。雷锋网雷锋网雷锋网

参考来源：

https://www.ithome.com/0/545/322.htm

https://baijiahao.baidu.com/s?id=1599147764721090669&wfr=spider&for=pc

https://baijiahao.baidu.com/s?id=1696644224851971641&wfr=spider&for=pc

https://new.qq.com/rain/a/20210410A07KKY00

https://baijiahao.baidu.com/s?id=1696644224851971641&wfr=spider&for=pc

中国央企国企信息化热点_阿朱=行业趋势+开发管理+架构-CSDN博客

Sun, 01 Nov 2020 11:20:25 CST

（1）应用

我很奇怪：大家觉得变化越来越快，我为啥感觉变化越来越慢呢？

你看很多企业，仍然停留在四大管控：

财务统一管控

人力统一管控

流程统一管控

数据统一管控

而且，即使是这四大管控，其实后两个管控也没搞，就是主要做财务统一管控和人力统一管控。

对于流程统一管控，不外乎用用OA和工作流引擎。连流程管理部也没有，也没有人对流程的质量、效率、成本进行衡量，也没有人对衡量进行绩效考核，每个部门都按日积月累混沌形成的日常事实运转过程滴答滴答走着。还有一些企业还和我叫：我们有进步啊，我们把泛微、蓝凌、致远传统OA软件换成了移动钉钉和企业微信了。（这到底是什么鬼逻辑？）

对于数据统一管控，我曾经参加过无数的CIO群，从QQ群参加到微信群，都持续够十五年之久。但是这十五年来，这些CIO老生常谈的老是：

数据缺失

数据错误

数据没标准

数据不统一

这四大数据问题，都谈论二十年了，还是没有任何结果和实质进展。还在谈。这就是中国大部分CIO的水平写照。后来，我把这些CIO群全都退了。

另外，我再说说财务统一管控。其实财务统一管控早就好几代思想了：

第一代：整个集团所有子公司、分公司，统一上一套财务软件，目的是把统一的财务制度要求内置到这套财务软件中共同遵守

第二代：财务共享中心，把全国各地的财务人员都集约化到总部，目的是通过工业化流水线来实现财务工作效率加速和财务人员成本集约

第三代：正是现在正在搞的，但是在欧美上世纪60年代已经搞的。那就是企业财务管理公司，目的是集中统筹企业的资金运用，最大化发挥资金效率

第四代：欧美在上世纪70年代已经搞的，那就是外包给社会专业的会计师事务所或财务管理公司，目的是把事务性工作都外包，自己本公司的正式编制正式工作主要从事创造性的事情。只有创造性的事情才是增值的高利润的事情

中国大部分企业都停留在第一代。甚至更多的企业还停留在地下：那就是每个大区自行采购自行信息化。蛮符合中国地方割据封疆大吏的千古规律。

最后我再谈谈人力统一管控。很多人力部长和我谈编制、薪资、绩效、激励。我说啊，这些都谈不上。未来你们负责的这摊事：面临的最大的挑战就是：央企国企民企并购重组。咱就不谈别的，就说HR系统里的组织管理和人员管理吧，你们能不能很容易做到两个不同的央企国企的组织和人员很快地在HR IT系统里面做合并重组。咱们把这个问题解决了再谈上面的各个点上的应用。

（2）技术

很多企业的IT系统，用的技术极为落后。这都什么年月了，Web技术互联网早在2009年就结束了，移动App技术互联网也已经十周年了。但大部分企业，全国那么多子公司分公司、甚至在全球开展业务，都还是类Windows的客户端，或者是需要在每台电脑上都要装600M甚至1个G的插件。是每台电脑都要装啊，还要维护不出异常，还要升级。天哪，真不知道那些全国分公司全球子公司的企业是怎么做到的，还能正常运转这么二十年。

所以，很多企业现在特别求所谓的IT体验，不外乎是：纯WebUI、移动App UI、小程序UI。这都算先进的了。

另外，很多大企业现在特别热衷微服务中间件技术，以为微服务能解决过去软件重型大块不好升级、不好拆分、性能低下的问题。我想说的是：微服务技术的产生初衷，根本不是为了解决应用拆分的问题。我过去早就写过文章《从来没有一种技术是为了解决复用、灵活组合、定制开发的问题》，我在这里就不赘述了。大家点击链接去看。大家想解决的应用好拆合的问题，需要IT系统的每个模块以及整体系统上，在产品设计、应用架构设计、技术架构设计方面都得一起努力才能解决，不能说用了微服务中间件，就真的是微服务了，就真的好组合了，这不现实。

还有很多大企业现在也特别热衷大数据技术。我就纳了闷了，按说中国的海量数据应该在中国政府手里，或者在互联网电子商务企业手里，因为他们的本质都是社会性组织。单个其他企业怎么可能会有海量数据呢？后来我反复追问才弄明白，原来他们想用大数据平台解决刚才我提到的数据统一管控的问题。

我说他娘的你们全错了：大数据平台根本解决不了你们说的：数据缺失、数据错误、数据没标准、数据不统一这四大数据问题。

很多人问：那用什么解决呢？

我告诉大家怎么真正解决吧。但，我一会说的方法也是只是最大化缓解，而不能彻底解决，就和应用好拆合一样，没有终极彻底方案，所以请大家都现实点看问题。但我一会说的方法，绝对比你们现在能想到的方法都要好。

首先，做业务中台。过去呢是，各个来源来的数据，都往数据库这个桶里装。放到桶里再看怎么统一。所以做了许多所谓的：数据整合、数据清洗的事情。这就晚啦。应该是，用业务中台去解决问题。比如说现在搞电商，有来自京东的订单，有来自淘宝的订单，有来自微信的订单，有来自抖音的订单，如果你不经过一个业务中台来收拢一下，你直接放进数据库这个桶里，那就不好统一了，都成酱缸了。所以需要统一订单中心，定义统一规则。很多ERP厂商乙方不明白为啥现在的大企业都开始在云计算技术基础上都自己开发了，很多很多ERP厂商乙方不明白怎么会有业务中台这个伪命题这个王八混账东西，还一个劲说攻击：有钱的企业上了中台没钱了，没钱的企业上了中台死了。这就是水平啊。

然后，做主数据服务。尤其是企业、供应商、客户、产品、项目、科目，都搞成主数据，对外提供Open API服务，就这一份主数据，而不是N份主数据。还要在主数据上打标签，做关系图谱。否则这主数据在财务、生产、采购、销售、售后各个部门会越用越乱。

最后再说说私有云。很多大企业都现在兴奋地要搞私有云，说我们要高科技。这是什么脑回路逻辑？上了私有云就是高科技就是进步？私有云有个毛用？

我曾经问过CIO，你们上私有云有个毛用？

他们说：上云是未来啊。

我说：上公有云才是未来，你们上的可是私有云啊，私有云又不是未来。你们说说，你们为啥要上云技术？咱们先不谈公有云私有云，咱们先掰掰你们为啥要上云技术。现在不香吗？

他们说：现在不香。现在每搞一个应用都需要搞一台服务器，老板对服务器增加很难批预算。但是多个不同厂家的应用放一台服务器，我们也不知道会不会出啥问题，除了问题算谁的？所以我们需要上私有云技术。用容器或者虚拟机把这些应用都隔离了。

我说：我晕。我2006年就在用虚拟机集群管理软件，同志们，现在都2020年了，再有2个月就2021年了。这十五年前该做的事，现在才做啊。你们这都落后多少年了。你们这么多年到底干了些什么。另外，OpenStack也推出十年了。另外，容器也推出6年了。

还有，大家是用公有云技术解决互联网应用社会化应用波峰波谷弹性收缩的问题。现在大家都在搞营销云、全渠道零售云、社交化客户关系运营，所以才需求公有云的技术。你们啥也不搞，就企业这点员工、就企业这个内部管理摊子，你们就根本没有上云技术的诉求。你们就是环境隔离而已啊。

就这水平。还当前沿，还以为能解决性能扩张问题？这都什么脑子。

腾讯信息流热点挖掘技术实践

Sun, 20 Sep 2020 00:00:00 CST

分享嘉宾：罗锦文腾讯研究员

编辑整理：Jane Zhang

出品平台：DataFunTalk

导读：当前各大资讯社交类APP都在显著的版面展示或者推荐热点相关内容，信息流应用能否快速发现热点、引导用户阅读热点，是影响用户体验的重要因素。本次分享主要介绍腾讯在热点挖掘方面的工作。基于搜索数据和自媒体文章，通过时序分析方法和内容聚类相结合的方法挖掘热点，并将热点聚类成事件和话题。用户搜索和媒体生产能够从消费和生产两个方面更加准确的度量热度，事件和话题同时能够辅助用户理解，做到热点的个性化下发，从而提升信息流热点体验。本文主要内容包括：

项目背景
相关研究方法
热点计算框架
热点挖掘
热点应用

项目背景

1. 热点应用场景

当前各大资讯类的产品都在显著的版面上展示和推荐热点相关内容，针对热点内容的推荐和呈现也变得非常多元化，比如：微博有微博热搜榜；知乎通过事件讨论的形式运营热点；百度有历史悠久的百度热搜榜；头条通过兴趣推荐的方式做热点分发频道，腾讯在对大事件做脉络运营。当前各大产品都对热点进行了大量的投入，我们基于腾讯看点丰富的视频数据，深挖用户的兴趣内容，接下来看下我们在腾讯看点的推荐频道页。

2. 热点核心推荐问题

这里对腾讯看点进行问题的分析，当前基于热点的问题存在以下几个问题：

及时性。热点挖掘需要及时监控全网站点，以科比去世为例，及时发现这一事件，并挖掘出来对应报道，才能有效帮助热点进行推荐和分发。
全面性问题。不同站点对热点的呈现不同，需要将事件榜单、话题榜单和对应的多种报道合理组织起来。比如，当一篇"南宁-工厂发生火灾"文章入库后，热点挖掘能否判断已有的挖掘结果与之对应，才能更好地进行推荐。
热度合理性问题。热度值是热度的重要特征，不同的数据源的事件热度各有不同，比如微博热搜榜当时有"钱峰又胖了"的话题，排在微博热搜榜很高的位置上，但是由于不同媒体的受众不同，在看点这边就很少有文章报道或者有用户去阅读。
热点分发的问题。热点文章和视频都有冷启动的问题，如在北京朝阳疫情定为高风险时，大部分是根据兴趣点推荐的，最近一段时间大家的用户画像中提出来"疫情"这个特征，如果基于疫情进行下发，非北京地区的用户不关注这个文章，这会降低系统的分发效率。因此要进行泛化，比如泛化到"北京疫情"这样的话题，来做用户分发，以此解决这篇文章冷启动的问题。

接下来能看到热点推荐有没有从事件推荐的角度来理解文章。有没有从事件的角度来理解文章，是提升热点推荐效果需要重点讨论的点。带着这几个问题，来看看传统的相关研究是怎么解决这个问题的。

02 相关研究方法

1. 事件抽取

任务定义：

作为信息抽取的一个重要任务，事件抽取是从一个无结构化的文本中自动抽取出来结构化的知识。以ACE任务为例，事件抽取可以分为事件检测和事件要素提取。事件检测是识别句子中的触发词trigger，这个词是描述时间的核心动作，然后根据预先定义好的框架，进行事件类型分类，因此事件分类是一个封闭集合。我是科比的粉丝，专门研究过科比不幸遇难时的相关报道，以科比去世为例，这里"凌晨四点，NBA球星科比布莱恩坠机身亡"，可以识别出trigger词为"身亡"，事件类型分类为die – 死亡事件类型，对应的事件要素是：event frame，包括：施害者、受害者、事件、地点等。通过事件提取的方式，能提到时间是"凌晨四点"，受害者是"科比·布莱恩"，把受害者和时间对应起来。这就是一个比较完整的事件抽取过程。

问题点：

可以看到事件抽取任务，是针对原子事件，通常是不可再分的，如通常提及的"新冠疫情爆发"，"南方洪水成灾"，这是有很多子事件的，不能通过事件抽取挖掘出来，同时事件框架要提前定义好，但是事件类型有限，难以覆盖新涌现出来的事件，因此只将事件抽取作为一个重要的特征抽取工具。

2. 话题检测与追踪 ( TDT )

接下来的任务和热点挖掘更相关，就是话题检测与追踪中的TDT任务，这个任务有20多年的历史了，定义的是处理新闻报道的系统。输入可以是固定的文章或者流式数据，结果是以聚类的方式将文档组织起来的话题。

话题检测：检测和组织系统中未预先设定的话题，也就是新话题的发现。

事件追踪：新到达系统的报道是否是已知话题的后续报道，也就是把新到达的文章和已有话题算相似度。

通常研究方法分为2类：

第一类算法是寻找TDT任务中的新的聚类算法，或对已有聚类算法的改造，常用的算法有：k-means、DBSCAN、层次聚类；
第二类算法是挖掘新的聚类特征来提高TDT任务的计算效果，如使用文本的语义特征、分类特征、实体特征、上面事件抽取提到的特征，和任务结合起来，计算更准确的相似度。当然TDT也有很多别的子任务，大家有兴趣可以去看一下。

突发事件监测：TDT为我们处理海量数据提供了很多新的解决思路，之后衍生出来了突发事件检测任务，值得关注。突发特征指的是伴随着事件的发生，若干与该事件密切相关的特征出现反常现象，比如文档、词语的爆发，比如南方下暴雨，暴雨这个词就会比去年或者前几个月的时序有明显的不同，最近是一个显著爆发的特征。我们可以通过检测突发特征来发现事件，这类研究目标与TDT任务不同，不再局限于传统的新闻报道，可以针对多类型的数据，比如微博、搜索、视频数据，受此输入的影响，我们将时序分析方法和话题聚类相结合，来提升热点挖掘的效果，以上方法都能很好地指导我们进行热点挖掘的工作。

接下来针对腾讯海量的数据和数据类型多的特点，提出了我们自己的热点计算框架，下面简单介绍。

03 热点计算框架

1. 总框架

整体分两部分：离线挖掘和在线理解，离线挖掘内容非常丰富，着重讲这块。

离线挖掘流程：先是资源引入，有3个不同的端，腾讯看点浏览器、qq浏览器、qq里的腾讯看点频道，接入丰富的数据之后，通过话题抽取，来提取热点特征，进行话题融合，把挖掘到的结果聚类成话题，再把话题拆分成对应的事件。

为什么先做话题聚类，再做事件拆分呢？

还以科比去世为例。当时描述这个话题，一部分报道的是"科比意外身亡"，另一部分报道"科比妻子悲痛欲绝"，以及"明星悼念科比"。当事件在凌晨刚发生的时候，只有一个媒体和几家论坛报道了这个事情，算法比较难把主要描述"明星悼念科比"和"科比意外身亡"的文章拆成两个，看做一个更加合理，文章增加一两个小时后，很多媒体从不同的角度描述这个事件，文章的丰富程度足以支撑我们把这个话题拆封成合理的较细的粒度，这个细分是比较符合用户兴趣的，比如女性用户更加关心科比妻子的情况，而对一些外国明星悼念科比不那么感兴趣，因此能够以更加有针对性的事件的粒度推荐，提升热点推荐的效果。

详细流程：

① 热点挖掘热点挖掘是为了满足全面性、及时性的要求，把热点挖掘拆为定时任务和流式任务。

定时任务：主要是搜索点击的特征、搜索词文章中的关键词的时序特征，与文章内容聚类的方式结合，把描述相近资源的文章聚合在一起，以话题形式组织起来。
流式任务：将入库的文章，及时通过事件判断过滤掉非事件内容，提升计算流程的时效性。

② 话题融合经过话题挖掘和实践挖掘后，进行话题融合。话题是对向上泛化，需要话题解析模块，将不同输入来源的热点信息以特征提取，与流式处理的融合，组织成话题的粒度；最后通过话题融合模块，从3个不同的角度定义一个热度，这样定好的热度，更加符合平台用户的热度感知，这样能帮助我们进行热点推荐。 ③ 事件拆分得到话题后，为了有效组织事件内容，需要对话题进行拆分，通过对事件命名的方式，把事件以简短的名称组织起来，得到事件tag，这样能支持线上使用，如事件榜单、事件脉络等，事件的核心词和热词进行热度匹配，把事件统一管理起来服务于热点相关的应用。

为什么要做话题库和事件库？

以近期的"暴雨资讯"为例，用户感兴趣的是"安徽特发特大暴雨"的事件内容，而非提及暴雨的文章 ( 比如"日本暴雨导致山洪爆发" )，我们需要把不同的数据源以话题库的形式组织起来，帮助热点推荐以跳出关键词 ( "暴雨" ) 推荐的限制，为用户提供更加符合其兴趣的内容。有了热点计算框架后，我们看看在应用场景上如何落地。

04 热点挖掘

1. QueryLog热点挖掘

第一个是基于query的热点挖掘。

① 预处理：构造Query时序数据

基于这样的假设：如果热点热门，用户有了解详细内容的需求。会通过query去搜索事件详情，因此我们以query为数据来源，这是一个显而易见的事情。如南宁发生火灾，用户会搜索南宁工厂，了解具体的伤亡情况。用户的搜索多种多样，基于突发热点能检测的方式，常见的是根据搜索词构建时间序列，使用BRD算法计算突发性，突发性需要进行分段处理、斜率检测、需要做分段设计，难以维护。我们构造了query热点计算流程来解决这个问题。

② 热门识别：时序分析，识别热门Query

首先是构造这个时序之后，通过时间序列分析来识别热门query，具体做法：定义一个热门query的趋势模板，前面几天平滑，最近有一个上升的趋势；或者小幅度上升，近期然后突然下降、热度减退的模板，这样计算事件的相似度，如果符合，就认为是热门的query，否则就不是。

相似度计算最开始是使用欧拉距离，需要把时间轴上的两个点做严格对齐。虽然趋势一致，但是欧拉对齐会导致相似度计算值较低，会带来bad case，后来使用DTW ( 动态时间规划 ) 算法，使用动态规划的方式来对齐时间序列，能更好捕捉趋势相似的情况。

③ 话题检测：相似Query聚类，形成话题

挖掘到热门query之后，可以发现用户的搜索比较随意，同一个事件的描述也是多种多样，对应多个query，所以需要把相同事件的query聚集起来，构造一个话题，与TDT中的无监督有所不同，搜索可以使用点击二部图的方式，以不同的query 可以点到同一个标题时，认为这两个query相似，结合语义特征，比如"吴亦凡女友"和"吴亦凡恋情"，语义比较相似；还有实体特征，"科比退役""姚明退役"，虽然两个都带有"退役"，看起来字面相似度较高，但是"科比"和"姚明"在事件中是不同的主题，可以对相似度降权。最后对相似度的综合得到更好地query相似度量，得到话题聚类结构。这里可以看到将query到话题的聚类。

最后，我们可以看到用户行为的话题检测，可以帮我们有效度量话题的消费热度。为什么是消费热度呢？是因为用户非主动搜索内容，表示用户有主动的消费意愿，所以是消费热度。这也是非常有效的话题度量方式。

④ 事件识别

在话题检测之前，当话题达到可拆分时，我们会对事件做拆分。常见的话题会伴随非事件的话题，比如热门美剧更新时，会出现热度突发，这样会混合这些query，因此基于监督做事件分类。比如词特征、点击信息，把"下载"去掉，url中的站点信息、域名信息加入进去，train一个分类器，可以有效识别出来哪些是事件、哪些是非事件。

事件命名，组里的同学在之前通过词法分析工具的基础上，提取了一个新的事件命名方式，基于query 和title构造图模型，来挖掘事件concept和event的命名。这是之前话题挖掘的延续，这个任务已经发表在SIGMOD 2020上，大家有兴趣可以做详细阅读。当前挖掘效果每天新增100+事件，准确率人工评估95+。可以看到对当前的挖掘效果，在传统上的提升。

2. 资讯文章热点挖掘

作为信息流服务的团队，每天打交道最多的是海量数据。当热门发生时，自媒体作者会主动跟进热点，创作文章跟进这些内容，比如当科比去世的一个小时后，即便是凌晨四点，作者也会也及时更新做报道。

挖掘主要是采用聚类的方式，离线的方式是将文章的数据按照固定发布时间做切分，通过batch learning对文章进行聚类，k-means、层次聚类这些方法会忽略这样的问题：每天有很多如描述刘德华过往文章，如果直接套用聚类算法会挖掘出来并非热点，会影响用户体验。热点文章包含时效性，如果直接套用聚类，没考虑时效性。传统的突发事件检测Graph event detection是基于二项分布或者傅里叶变化的方法发现突发次，这些突发次会持续一段时间的增长，而非突发的一个尖点。并且基于词粒度的挖掘会带来很多bad case，NLP同学都会发现这样的问题。切词的粒度不可控。

基于这些问题，提出了新的挖掘方式： 基于关键词和动态时间规划的方法来进行事件挖掘。

我们这里使用的处理方式：

① 预处理及热门识别

关键词描述文章主体，借助组内篇章理解的能力，将文章特征转换为关键词特征，与query挖掘相似，将关键词在文章库中出现的频次，构造时间序列，再用DTW算法与固定的模板做匹配，得到挖掘到的热门关键词。比如暴雨，或者前段时间北京6月份疫情，三文鱼突然热起来，通过这种方式挖掘出来"三文鱼"热门关键词，能召回很多描述新发地疫情相关的文章。当时召回的文章的acc和 recall都很高。接下来回到暴雨，通过暴雨召回所有和暴雨相关的文章，再构造热门关键词的实体特征，包括抽取的地点，安徽、合肥，加入实体特征，再用语言模型提取title的特征，计算相似度，3个相似度综合得到文章自底向下的层次聚类，从而得把南方暴雨聚成一个话题。而之前提到的"日本山洪爆发"，虽然提到了暴雨，相似度较低，会聚类为一个孤立的点，可以过滤掉。

② 话题检测

在这之后，同样是聚类，得到的话题是自媒体创作的文章。自媒体作者可以认为是专家用户，他们创作文章的数量，可度量话题热度，定义为生产热度。

③ 事件拆分

然后做事件拆分，以"江西洪涝致699万人受灾"和"重庆暴雨成灾"两个事件为例，基于看点的数据分布，作为一个触发词发现和元素抽取任务，就可以得到受灾和成灾的trigger相似，但argument不相似，这样可以把话题合理拆分成两个不同的时间，拆分为时间后，通过rank，可以把聚类为相似度较高的标题抽出来，然后基于seq2seq + attention的方式，形成可以展示的事件名称，从而得到合理的拆分和事件命名。

④ 热度计算

还可以得到事件库，可以query挖掘得到的消费热度，基于咨询得到的生产热度，基于全网的监控的全网热度，综合起来，对挖掘到的热门文章，进行合理的热度，帮助推荐系统做推荐，提供更好的热度特征。

通过热点挖掘算法，得到更加满足用户兴趣的话题集合、事件集合和对应的热度。

接下来看在热点推荐场景下如何应用起来。

05 热点应用

1. 图文热点应用

图文热点应用。资讯库是流式文章入库，在线理解借助语义匹配模型，将新入库的文章和已有的事件库关联起来，使用的是双塔结构和MatchPyramid模型结合，将文章标题和事件的名称的BOW特征，计算语义相关度，而MatchPyramid模型则构造事件词与文章内容的交互矩阵，比如事件名称包含6个词，文章选择前300个词，是300维，得到6*300的矩阵，做卷积计算，得到一个相似度量，将这两个做线性融合，得到显性匹配的分。这样也可以把在线文章进入事件库，赋上事件标签、话题标签、综合热度，给推荐系统使用。在事件匹配的准确率上，也达到了较高的标准，事件覆盖效果也比较好。

这不仅可以用在图文挖掘上，也可以用在视频、小视频热点挖掘中。

2. 视频&小视频热点

视频&小视频热中的应用，主要是基于热点挖掘得到的文本信息，将图文计算的热点传递给视频和小视频，怎么做的呢？视频能够准确打出影视综合明星tag，通过已挖掘好的热门词库，可以筛选出来近期热门的影视明星类的视频和小视频。我们还会解决这样的问题，比如快乐大本营已经播了很多年，经常出现老片段新发，或者明星自制的明星短剧，需要借助视频关键词、作者的信息、人工标签，过滤掉非热门视频，得到热门视频的候选。另一个是基于新闻报道的视频，人工不知道事件的前提下，直接打事件标签很困难，需要借助已经挖掘到的事件库，和视频标题做匹配，匹配近期的热门事件的视频和小视频，如"科比坠机"，可以匹配到"科比去世"，"科比坠机身亡事件"，得到这些标题后，进入热门视频库中，帮助推荐系统给用户推荐更加热门的视频和小视频。

今天的分享就到这里，谢谢大家。

在文末分享、点赞、在看，给个三连击呗~~

嘉宾介绍：

罗锦文

腾讯 | 研究员

本科毕业于兰州大学，研究生毕业于北京大学。2016年阿里实习，然后2017下半年转战百度实习，于18年加入腾讯正式工作，负责新NLP新热内容挖掘和词法分析相关工作。

社群推荐：

欢迎加入 DataFunTalk NLP 算法交流群，跟同行零距离交流。如想进群，请识别下面的二维码，回复“ NLP”入群。

文章推荐：

腾讯信息流内容理解技术实践

关于我们：

DataFunTalk 专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100场线下沙龙、论坛及峰会，已邀请近500位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章300+，百万+阅读，7万+精准粉丝。

分享、点赞、在看，给个 三连击呗！

中国企业信息化老讲降本增效，是不对的_阿朱=行业趋势+开发管理+架构-CSDN博客

Tue, 25 Aug 2020 21:30:45 CST

中国企业信息化老讲降本增效，这个我是不认同的。我就讲究两个重心：

1、业务增长：在线业务电子商务

2、避险合规：内部管

家族托管基金-投资-所有权和经营权分离-职业经理人，这是欧美的一条链。

为了让双方互相放心，就产生了：

咨询顾问、流程梳理

审计师会计师事务所、华尔街分析师评级师

IT固化：流程固化、联网一查到底、数据透明

中国没有：家族托管基金Old Money，也就没有职业经理人。

但是，中国也有很多避险合规的要求。

如果一个中国实业企业，没有以下任何一条需求，那么它可能就不需要购买ERP软件。

（1）来源一：国际

一、国际贸易要求

1、出口标准

2、海关

二、国际资本要求

1、华尔街上市、并购

2、审计、评级

如果你不是出口企业&出口制造企业，不是海外（香港、美国等）上市企业，这两条无效。

（2）来源二：国内

一、政府监管

1、安监、环保监、食药监

2、工商、税务

3、社保

如果你不属于监管敏感性行业，那这条对你也是弱约束。

二、金融监管

1、银行：如果你不是依赖银行贷款的，这条对你也是弱约束

（3）来源三：客户

一、国际客户

需要遵照国际游戏规则和标准

如果你没有国际客户，那这条没有约束性。

二、国内客户

尤其是央企国企，大家都要保平安。所以招投标需要各种合规资质、合规审核，以便保证招投标顺利

如果你的客户不是以央企国企为主，那这条也没有约束性。

（4）来源四：自己

一、集团

中国很多集团型企业是跨地区、多元化综合型的投资集团，是由投资或者兼并重组而来的集团。所以子公司孙公司、控股公司参股公司众多。为了防止下面的成员机构出问题带害上市主体，所以需要搞集团统一管控，尤其在：

1、采购统一管控：

2、财务统一管控：很多集团尤其在总账统一管理、资金统一管理、固定资产统一管理方面需求突出

3、人力统一管控：尤其在组织、人事安排、薪资管理、绩效考核

4、审批统一管控

5、标准主数据统一管控

甚至有的集团还要直接获得客户反馈客户投诉，防止一线公司胡作非为、屏蔽客户，所以有的集团还搞：客户关系中心，统一客户管控。

当然，如果你不是集团型企业，你对统一管控也没啥太多需求。

我所认知的甲方信息安全建设经验

Mon, 13 Jul 2020 00:00:00 CST

推开门　烟火中的红尘　宣纸上　是故事里的人

　　毕业至今，从最初在乙方安全厂商做安全服务，辗转到互联网公司做安全研发，现今在金融国企做安全建设工作。几年信息安全职业生涯，我经历了从乙方到甲方的角色转换，经历了从互联网到国企的转变。兜兜转转的几年时间里，随着日常工作内容的改变，我对信息安全的认知也发生了一些变化。本篇我将记录总结一些甲方信息安全建设方面的经验，仅代表此时此刻我对于信息安全建设的一些认知（说明：甲方信息安全建设涉及内容太宽泛，本篇大致列举一些信息安全建设方面的措施，具体细节之后会单独记录成文）

网络系统安全建设

安全域划分

内部网络系统：主要指OA办公网内部、生产网内部、测试开发网内部、以及其他内部网络系统。
外部网络系统：主要指OA办公网互联网边界、生产网互联网边界、测试开发网互联网边界、互联网上相关所属的网络系统（不限于：公有云、Github、云存储等）。

安全域风险等级

外部网络系统>生产网内部网络系统>测试开发网内部网络系统>办公网内部网络系统>其他网络系统

安全域风险对象

外部系统：外部攻击者（黑客、白帽子）
内部系统：内部违规操作员工、已渗透到内网系统的外部攻击者

安全建设方案

　　由于不同安全域的风险等级、风险对象有所区别，因此我个人认为不同安全域的安全建设方案也该因地制宜。以下文章篇幅，我将根据不同安全域通过事前、事中、事后三个方面记录信息安全建设思路。

办公网-网络安全建设

WIFI安全

事前安全措施：1、建立双因素认证（通过个人账户密码+短信、动态密码）；2、建立设备安全认证（限定特定的设备才能连接）
事中安全措施：1、建议WIFI账号爆破监控；2、WIFI账号爆破封禁策略运营

VPN安全

事前安全措施：1、远程接入公司内部网络进行双因素认证（个人账户密码+短信、动态密码）；2、硬件指纹获取识别
事中安全措施：1、VPN异地登录；2、异常登录监控；3、VPN爆破监控以及封禁策略
事后安全措施：1、联系VPN账号所属者确定攻击行为

日志流量采集检测

事前安全措施：1、办公网网络流量（到边界、到IDC）；2、日志采集检测
事中安全措施：1、员工异常行为监控（比如上传内部数据到网盘等）；2、攻击监控
事后安全措施：1、对涉事员工进行相应处罚

Router统一管理

事前安全措施：1、即统一管理内部网络映射到外网需求（可利用nginx反向代理），减少系统暴露风险
事中安全措施：1、外网端口扫描监控

终端网络准入

事前安全措施：1、办公终端（PC）需要安装准入程序，才允许上内部网络
事中安全措施：1、终端异常行为监控
事后安全措施：1、对涉事员工进行相应处罚

安全域之间网络隔离

例如：办公网与生产网之间只能通过堡垒机登录，且只有特定端口才能通信等策略（根据实际情况配置）

办公网-系统安全建设

办公网服务器安全

事前安全措施：1、服务器基线检查；2、补丁检查；3、端口服务监控；4、服务器登录统一管理
事中安全措施：1、服务器进程监控；2、敏感账户登录监控；3、敏感命令执行监控；4、文件上传下载等（依赖主机安全产品，服务器上安装Agent）
事后安全措施：1、服务器木马；2、后门查杀；3、服务器安全加固（服务器应急响应）

办公网终端PC安全

事前安全措施：1、防病毒；2、DLP；3、水印；4、行为监控
事中安全措施：1、DLP数据监控；2、水印监控

办公网-应用安全建设

SSO统一登录入口

事前安全措施：1、内部所有的办公系统使用一套SSO认证系统，可有效管理员工账户密码，预防弱口令等风险
事中安全措施：1、异常登录监控；2、弱口令监控
事后安全措施：1、强制修改用户账号密码；2、加固SSO

网站水印技术

事前安全措施：1、对有重要敏感数据的网站加上水印，防止数据被截图泄露等风险
事中安全措施：1、水印攻防监控
事后安全措施：1、对涉事员工进行相应处罚

邮箱安全

事前安全措施：1、邮箱访问安全加固方案，用来解决邮箱接口被爆破风险；2、附件安全扫描；3、异地登录报警；4、弱口令扫描
事中安全措施：1、邮件爆破监控；2、账户或者IP封禁；3、异地登录监控
事后安全措施：1、若爆破成功，则强制修改相关员工密码，且排查安全风险

WAF

事前安全措施：1、应用服务器上部署WAF，拦截web攻击
事中安全措施：2、WAF上进行攻击监测
事后安全措施：3、更新优化WAF拦截策略

办公网-员工安全

在职员工安全教育

事前安全措施：1、定期对所有员工进行安全培训；2、对新员工进行入职安全培训；3、定期开展内部钓鱼测试；
4、针对RD可培训WEB安全开发；5、针对OP可培训安全运维。
事中安全措施：1、对员工行为进行监控（可通过前面介绍的几种方案）；2、对钓鱼邮件进行告警
事后安全措施：1、对涉事员工进行相应处罚；2、钓鱼邮件影响评估

离职员工安全审计

1、离职行为审计；2、办公电脑审计；3、人员离职账户注销

办公网-外包安全管理

暂无涉猎

办公网-安全合规

1、ISO27001；2、等保2.0

生产网-系统安全建设

主机安全:1、内部资产发现；2、webshell监控；3、反弹shell监控等日常运营工作
日志分析监控：1、可以偏业务一些，比如接口防刷监控运维；2、也可以偏系统一些，攻击行为的监控运维
网络抗DDOS、应用抗CC：主要靠部署一些流量清洗产品
入侵检测、防御：IDS、IPS（对于告警记录的运维工作）
堡垒机：服务器统一登录管理，秘钥管理，访问控制策略运维工作
Router层统一映射管理：互联网端口、IP映射管理，结合cmdb平台运维工作
WAF：部署waf产品，拦截WEB攻击，告警记录运营工作
端口开放策略（ACL）
IPTABLES
态势感知（SOC平台）：流量监控平台，通过监控不同方向的流量，发现攻击行为
蜜罐（欺骗防御）：通过在内、外部部署蜜罐产品，发现攻击行为
邮件沙箱、网关：针对邮件钓鱼、恶意附件的检测
威胁情报：往往跟态势感知相结合

除了系统层面的安全建设，生产网更多的是跟运维相关的一些安全内容（比如安全基线等），也包含项目上线的一些安全流程规范管理。

外网边界安全建设

资产收集：IP、域名、URL、数据接口、端口服务监控，梳理统计内外网端口映射关系、业务线负责人等信息，盘点边界资产。
黑盒漏洞扫描：WEB漏洞扫描、主机漏洞扫描（可采购也可自研，定期巡检）
业务逻辑漏洞扫描：通过流量、日志被动式检测简单的业务逻辑漏洞
GITHUB监控：自动化监控github泄露的公司相关代码、服务器个人相关信息等
SRC上报漏洞响应：建设SRC平台，收集白帽子提交的安全漏洞
最新漏洞、0day响应：0day、1day漏洞的研究、应急团队，推动漏洞修复
威胁情报
渗透测试：定期开展从互联网边界实施的渗透测试工作，寻找安全漏洞

外网边界的安全建设工作，大致分为三个步骤：资产盘点、漏洞扫描、漏洞推修（定期重复），0day漏洞应急另算。

产品安全建设

第一道防线：产品安全设计（早期可通过安全编码、意识培训使RD、PM具备信息安全意识）
第二道防线：需求评审、架构评审、代码审计、白盒扫描（通过建立需求安全评审等机制，严格控制新项目上线流程）
第三道防线：黑盒扫描、灰盒扫描（项目上线后可定期开展黑盒扫描）
第四道防线：SRC、企业蓝军（通过SRC、蓝军渗透发现的漏洞进行补充）

在整个产品安全建设过程中，企业可自研沉淀”产品安全开发库”、”SDL流程平台”以及制定”产品安全相关流程制度”。

企业红蓝对抗

企业红军：负责企业安全建设、安全监控、安全加固
企业蓝军：负责攻击安全堡垒、找出安全薄弱点

网络安全红军的工作包含了以上所有的安全建设工作，而网络安全蓝军的工作是一个全新的视角，包含不限于：

内部钓鱼攻击
外部漏洞攻击
APT攻击
内部爆破攻击
员工信息收集
……

企业在蓝军团队建设过程中，可自研沉淀：漏洞扫描器、社工库、漏洞库等

私有云安全

有些企业内部会建设私有云，关于私有云安全我接触不多，大致列一下所涉猎的内容：

网络安全：租户间的虚拟网络隔离、虚拟机与宿主机间的访问策略、同租户不同虚机间的访问策略等
数据安全：数据的备份加密、数据接口防重放、数据分级分类等
主机安全：防逃逸、内存溢出、入侵检测等
安全合规：等保2.0云安全相关章节

安全组织架构

小规模

若公司规模小，个人认为可按事前、事中、事后划分信息安全组织架构（仅供参考）

系统安全
事前团队：负责内外网安全建设
事中团队：负责入侵监控、异常监控
事后团队：负责应急响应、事后处罚整改
产品安全：SDL
安全合规
业务安全

大规模

若公司规模大，可按安全区域划分组织架构（仅供参考）

系统安全：
办公网团队：负责办公网安全建设、安全监控、应急响应（内部可再按照前、中、后细分，再细分，可分WEB、移动、硬件等）
生产网团队：负责生产网安全建设、安全监控、应急响应
外网边界团队：负责边界安全建设、安全监控、应急响应
产品安全：SDL
安全合规
蓝军团队：如果规模小可不用设置蓝军团队。蓝军团队是脱离安全区域之外的，但属于事前。
业务安全
云安全

总结说明：本篇内容用于记录我认知中，甲方信息安全建设可以涉及的一些措施或者说抓手。我认为信息安全建设就像建造一幢房子，目前我列出尚属于整体外部框架部分，具体细节需后续工作中不断实践、总结后补充沉淀

HttpSevletRequest Body信息多次读取填坑录-java

Fri, 05 Jun 2020 11:13:28 CST

1、背景

业务拦截器需要拦截request的所有传入信息。通常情况下,HttpServletRequst 中的 body 内容只会读取一次,但是可能某些情境下可能会读取多次,由于 body 内容是以流的形式存在,所以第一次读取完成后,第二次就无法读取了,一个典型的场景就是 Filter 在校验完成 body 的内容后,业务方法就无法继续读取流了,导致解析报错。

2、解决方案

我们是否可以用装饰器来修饰一下 request,使其可以包装读取的内容,供多次读取。

这个装饰器要符合httpsevletrequest接口规范，在原有的框架中spring boot提供了一个简单的封装器ContentCachingRequestWrapper，从源码上看这个封装器并不实用，没有封装http的底层流ServletInputStream信息，导致使用@RequestParam,@RequestBody等使用底层流构建的逻辑依然无用，只能硬生生的使用

  public byte[] getContentAsByteArray() {
   return this.cachedContent.toByteArray();
}
复制代码

来自己在业务中处理body信息。这里，我参照ContentCachingRequestWrapper封装了一个更具可靠性，更低侵入性的装饰器：

  package com.interceptor;

import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.io.IOUtils;
import org.apache.commons.lang.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpMethod;
import org.springframework.http.MediaType;
import org.springframework.lang.Nullable;
import org.springframework.web.util.WebUtils;

import javax.servlet.ReadListener;
import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
import java.io.*;
import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;

/**
 * @author sean
 */
public class RepeatReadHttpRequest extends HttpServletRequestWrapper {
    private static final Logger LOGGER = LoggerFactory.getLogger(RepeatReadHttpRequest.class);
    private final ByteArrayOutputStream cachedContent;
    private Map cachedForm;

    @Nullable
    private ServletInputStream inputStream;

    public RepeatReadHttpRequest(HttpServletRequest request) {
        super(request);
        this.cachedContent = new ByteArrayOutputStream();
        this.cachedForm = new HashMap<>();
        cacheData();
    }

    @Override
    public ServletInputStream getInputStream() throws IOException {
        this.inputStream = new RepeatReadInputStream(cachedContent.toByteArray());
        return this.inputStream;
    }

    @Override
    public String getCharacterEncoding() {
        String enc = super.getCharacterEncoding();
        return (enc != null ? enc : WebUtils.DEFAULT_CHARACTER_ENCODING);
    }

    @Override
    public BufferedReader getReader() throws IOException {
         return new BufferedReader(new InputStreamReader(getInputStream(), getCharacterEncoding()));
    }

    @Override
    public String getParameter(String name) {
        String value = null;
        if (isFormPost()) {
            String[] values = cachedForm.get(name);
            if (null != values && values.length > 0) {
                value = values[0];
            }
        }

        if (StringUtils.isEmpty(value)) {
            value = super.getParameter(name);
        }

        return value;
    }

    @Override
    public Map getParameterMap() {
        if (isFormPost() && !CollectionUtils.sizeIsEmpty(cachedForm)) {
            return cachedForm;
        }

        return super.getParameterMap();
    }

    @Override
    public Enumeration getParameterNames() {
        if (isFormPost() && !CollectionUtils.sizeIsEmpty(cachedForm)) {
            return Collections.enumeration(cachedForm.keySet());
        }

        return super.getParameterNames();
    }

    @Override
    public String[] getParameterValues(String name) {
        if (isFormPost() && !CollectionUtils.sizeIsEmpty(cachedForm)) {
            return cachedForm.get(name);
        }

        return super.getParameterValues(name);
    }

    private void cacheData() {
        try {
            if (isFormPost()) {
                this.cachedForm = super.getParameterMap();
            } else {
                ServletInputStream inputStream = super.getInputStream();
                IOUtils.copy(inputStream, this.cachedContent);
            }
        } catch (IOException e) {
            LOGGER.warn("[RepeatReadHttpRequest:cacheData], error: {}", e.getMessage());
        }

    }

    private boolean isFormPost() {
        String contentType = getContentType();
        return (contentType != null &&
                (contentType.contains(MediaType.APPLICATION_FORM_URLENCODED_VALUE) ||
                        contentType.contains(MediaType.MULTIPART_FORM_DATA_VALUE)) &&
                HttpMethod.POST.matches(getMethod()));
    }

    private static class RepeatReadInputStream extends ServletInputStream {
        private final ByteArrayInputStream inputStream;

        public RepeatReadInputStream(byte[] bytes) {
            this.inputStream = new ByteArrayInputStream(bytes);
        }

        @Override
        public int read() throws IOException {
            return this.inputStream.read();
        }

        @Override
        public int readLine(byte[] b, int off, int len) throws IOException {
            return this.inputStream.read(b, off, len);
        }

        @Override
        public boolean isFinished() {
            return this.inputStream.available() == 0;
        }

        @Override
        public boolean isReady() {
            return true;
        }

        @Override
        public void setReadListener(ReadListener listener) {

        }
    }
}
复制代码

使用这个装饰器时需要配合Filter对原有的request进行偷梁换柱，注册Filter并在调用链中将原有的request换成

  RepeatReadHttpRequest
package com.interceptor;

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.util.ContentCachingRequestWrapper;

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;

/**
 * @author sean
 * 拦截器httprequest替换 可重复获取inputstream
 */
@Configuration
public class FilterConfig {
    @Bean
    public FilterRegistrationBean requestReplaceFilterRegistration() {
        FilterRegistrationBean registrationBean = new FilterRegistrationBean();
        registrationBean.setFilter(new RequestReplaceFilter());
        registrationBean.addUrlPatterns("/*");
        registrationBean.setName("RequestReplaceFilter");
        registrationBean.setOrder(1);
        return registrationBean;
    }

    public static class RequestReplaceFilter implements Filter {
        @Override
        public void init(javax.servlet.FilterConfig filterConfig) throws ServletException {

        }

        @Override
        public void destroy() {

        }

        @Override
        public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
            filterChain.doFilter(new RepeatReadHttpRequest((HttpServletRequest) servletRequest), servletResponse);
        }
    }
}
复制代码

后续的request就可以使用封装器多次读取body信息。

腾讯在信息流内容理解技术上的解决方案

Wed, 01 Jan 2020 00:00:00 CST

作者：weidongguo，腾讯 PCG 应用研究员。

目前信息流推荐中使用的内容理解技术，主要有两部分构成：1、门户时代和搜索时代遗留的技术积累：分类、关键词以及知识图谱相关技术；2、深度学习带来的技术福利：embedding。但是分类对于兴趣点刻画太粗，实体又容易引起推荐多样性问题，而 embedding 技术又面临难以解释的问题。本文主要介绍在信息流推荐中，PCG 是如何做内容理解克服上述问题的。

项目背景

内容理解技术演进

门户时代：1995~2002 年，主要代表公司：Yahoo、网易、搜狐、腾讯。互联网初期，因为数据较少，因此需要一个内容聚合的地方，人们才能够快速的找到信息。因此，门户通过“内容类型”对内容进行整理，然后以频道页形式满足用户需求。因为数据少，初期由人工对新闻进行分类。随着数据的增多，靠人工分类已经变得不现实，因此各大公司纷纷引入分类技术，自动化文本分类。此后，文本分类技术发展迅速。
搜索/社交时代：2003 年~至今，主要代表公司：搜狗、腾讯、Google、百度。随着网络的普及，数据的数量和类型的丰富，门户网站已经不能够承载信息分发的任务。于是，一种新的信息分发技术诞生——搜索。搜索除了需要分类信息以外，还需要精确知道文章是

“关于什么的”，关键词技术很好的解决了这个需求，于是也成为那个时期的研究热点。但是关键词技术有一个问题没办法克服：实体歧义问题

( 如李白，究竟用户是找诗人李白，还是王者荣耀英雄李白 )。2012 年 Google 提出知识图谱概念，可以用于解决上述的实体歧义问题，实体链指的问题也有了比较大的进展。
智能时代：2012 年~至今，主要代表公司：今日头条、出门问问等。使用 2012 年来作为智能时代的开始，主要是这一年头条成立。头条定义了一种新的信息分发形式——个性化推荐。虽然个性化推荐技术早有研究，但是对于信息分发这个任务有不可或缺的推动作用。

但是在信息推荐中，我们仍然在使用分类、关键词和实体等传统的内容理解方法， 那到底在智能时代下是否需要新的内容理解方案呢？

用户为什么会消费

传统的内容理解仅仅解决了文章是什么的问题，但是对于用户 “为什么会消费”却没有考虑。举个例子来说，如果我们的一个朋友看了一款 XC60 的汽车，我们会给他推荐什么内容呢？我们一定不会不停的推荐 XC60，而是会猜测朋友可能是喜欢沃尔沃这个品牌，比较看重安全性，或者对于空间有一定要求的 SUV。因此，如果要做好一个推荐系统，内容理解同样也需要相应的能力，挖掘用户真实消费意图。

传统 NLP 技术缺陷

以上是整个项目的背景，我们总结一下：

分类：人工预定义，量级千规模；优点：结果可控性高，人工可以参与运营；缺点：粒度太粗，难以刻画用户粒度的兴趣点，推荐不精准；

关键词：规模庞大，量级可达千万；优点：技术成熟；缺点：绝大多数词不能反映用户兴趣，需要配合兴趣白名单一起使用，不能解决歧义的问题；

实体词：常见实体百万量级；优点：精准刻画用户兴趣，结果可控性高；缺点：推荐内容单一，容易造成信息茧房；

LDA：量级千规模，优点：技术成熟，可以人工预先选择出有意义的类簇；缺点：规模和分类相当，粒度太粗，与分类问题相同；

Embedding：量级不受限制；优点：研究热点，有成熟技术；缺点：难以解释。

个性化推荐需求：推荐系统需要积累用户模型，因此需要保留完整的上下文，语义粒度要完整；不同的人消费同一篇文章背后原因可能不同，因此需要有一定的推理能力。

因此，传统的内容理解方案并不能很好的满足个性化推荐的需求。个性化推荐不仅需要传统的内容理解方式，还需要一种能够有完整上下文，并且具有推理用户真实消费意图的能力。

兴趣图谱

兴趣点图谱(AG)概貌

根据上述分析，我们提出了兴趣点图谱，用于解决上述个性化推荐中遇到的问题。兴趣点图谱由四层组成： 分类层、概念层、实体词和事件层。下面分别介绍各层的内容：

分类层，一般是由 PM 建设，是一个严格树状的结构，一般在 1000 左右个节点，主要解决人工运营的需求；

概念层：有相同属性的一类实体称之为概念，例如老年人专用手机、省油耐用车等，推理用户消费的真实意图；

实体层：知识图谱中的实体，如：刘德华，华为 P10 等，负责一般兴趣点的召回；

事件层：用来刻画某一个事件，例如：王**离婚、三星手机爆炸等，事件层精准刻画文章内容。

下面介绍如何构造兴趣点图谱。

概念挖掘

概念本质是一种短语，其实短语挖掘的论文非常多，像 韩家炜老师团队就有很多相关的论文，但是概念有自己的独特性：

没有训练样本，并且人工难以标注。因此只能通过弱监督方法解决冷启动的问题，然后使用监督方式提升覆盖。
粒度问题，比如 “明星” 是一个概念，但是太泛，不能精准刻画用户兴趣，但是“身材好的女明星” 就很合理，那如何描述粒度呢？使用 UGC 数据，用户真实表达需求。

因此，具体挖掘时，我们使用了搜索数据，通过用户的点击行为进行半监督算法的学习。具体算法如上图所示：挖掘概念使用的是搜索数据，每一个概念都有多个点击的网页，对网页进行实体抽取，然后统计实体和概念的共现频次就可以获得较为准确的上下位关系，我们在

KDD 的 paper中有详细的介绍。

关联关系

个性化推荐系统中除了要满足用户当前兴趣以外，还需要探索到 用户未知的潜在兴趣点，扩展用户阅读视野。因此需要对节点计算关联关系。目前我们仅针对实体做了关联关系的计算。

大家很容易想到，如果两个实体经常会在同一篇文档中出现，应该就是高关联的；或者用户经常连续搜索，即搜完“刘德华”，然后会马上搜索“朱丽倩”，应该也是高关联的。确实这种直觉是正确的。虽然这种方法准确率很高，但是会遇到一些问题：没有共现过的，会被认为没有任何的关系；对于共现少的 pair 对，关系的密切度计算误差也会比较大。

因此，需要通过 实体向量化的形式克服上述问题。上述的共现数据可以作为正例，负样本采用同类实体随机负采样，正负样本比例 1:3，通过 pair wise 的 loss 进行训练，得到每个实体的 embedding，然后计算任意两个实体的关联度。

内容理解

文本分类

主题分类层是 PM 整理的，但是 PM 整理的过程中可能会存在一些认知偏差。可以使用用户的点击行为对内容进行聚类，聚完类之后让 PM 去标注，从而总结出一些更适合的类别用于描述用户的兴趣。

具体分类的方法，其实比较容易想到，分别使用作者、标题和正文三部分信息提取语义信息，然后合并到一起做 softmax 分类。这里为了线上效率没有使用很复杂的模型，但是线上效果还是不错的。

关键词抽取

我们使用了比较传统的关键词提取思路，利用传统特征工程 + GBRank 算法排序。在实际中会遇到这样的问题，如示例，Twitter 出现在 title 中的实体，传统的方式会把 Twitter 分数计算的很高，但是这篇文章中却不是重点，重点是两支 LOL 战队的骂战。于是我们在 BGRank 之后， 加了 re-rank 层，为所有的候选词做一个重排序。词之间边关系使用关联关系 embedding 计算相似度得到。

语义匹配

对于概念和事件类型的标签，原文中可能并不会出现，用抽取的方式就没有办法解决。我们采用召回+排序的方式解决。召回的逻辑分为 关系召回和语义召回，其中关系召回会用到兴趣点图谱中的关系数据，召回 1-hop 内的节点作为候选，语义召回通过语义向量召回与 title 近邻的节点作为候选，然后用交互匹配的方式进行排序。如果 1-hop 内的节点数量太多，排序耗时会非常大，因此这里采用粗糙集的方式进行候选的粗排，缩小候选集合再进行排序。

总结

本文详细分析了在信息流推荐中，传统 NLP 做内容理解时的局限性，以及新的要求。我们通过对实际用户行为的分析，总结了一套基于 兴趣点图谱的内容理解方案，并且在信息流的场景下应，取得了不错的效果提升。

错误信息提示在表单中的最佳位置

Sat, 01 Jun 2019 17:18:49 CST

在你的表单设计中，你会把错误信息提示放在哪个位置呢？如果它们不符合用户预期，就可能成为用户体验上的障碍。试想，当用户输入错误的信息时，他们首先需要理解错误是什么，然后才是修正错误、重新提交表单。但如果这个过程太费劲，他们可能就会选择放弃继续填写。

表单上方的有效性 VS 内部的有效性

最常见的错误信息提示放置位置是表单的上方或内部，那么哪个位置对用户来说体验更好呢？有研究发现，在表单上方显示错误信息提示，会对用户的记忆产生负担。当填写错误时，错误信息提示在最上方容易让用户在改正信息的时候要去回忆，到底是哪里填错了，怎样才能填正确。而把错误信息提示放在表单内部可以减少用户的记忆负担，用户主要依赖于即时识别而非回忆，所以会更快更简单地改正错误。另一个研究发现，“输入错误和错误信息提示的距离影响错误修正的效率”。把错误信息放在表单顶部或者底部，会导致用户修改错误所需的时间最长，而内联形式的错误信息提示所需要修改的时间是最短的。同时，将错误信息放在表单顶部或者底部在用户侧，错误率最高、修改时间最长，用户满意度也最低。其中，与顶部和内联相比，底部的提示具有最低的纠错成功率。

错误信息提示位置的用户偏好

研究证明，内联形式的错误提示可以得到最佳的用户体验，同时这项研究还给上下左右四个方向排了优先级（如下图）。参与这项研究的用户，对他们最满意的信息提示位置进行了评级，显示出了强烈的用户偏好。放置在左侧的错误消息被评为最差，在上方的被认为难以记忆，下方的被认为比较难记。

输入框右侧是最佳区域

理解为什么放在右侧能够符合用户习惯与期望是重要的。通过这种方式，设计师可以做出体验更好的产品。西方的阅读习惯是从左到右。当用户视线从输入到错误反馈，这是一个非常自然的过程，不需要动脑。从看到错误信息提示到输入改正错误，也需要遵循阅读习惯。

输入框左侧是最差区域

把错误信息提示放在左侧区域，违背了西方的阅读习惯。当错误信息提示出现的时候，用户的视觉动线需要朝着阅读习惯的反方向移动。这会让用户感觉到不自然，而且这会违反直觉，因为用户预期高优先级的元素应该是在左侧。把错误信息提示放在左侧让人感觉比输入项更重要。但是输入内容显然是更重要的，因为用户需要聚焦在输入框上，修正他们的输入。

输入框的上方增加识别负担

当错误信息提示放在输入框的上方，而表格上方有标签项的时候，用户会经历更高的认知负担。这是因为错误信息提示和标签混在一起，很容易让用户产生疑惑。根据临近原则，当用户尝试去阅读错误信息提示或标签的时候，这两个文本会产生视觉混乱，所以结果是难以聚焦而让用户分心。

错误信息提示在移动端表单的最佳位置

手机屏幕缺少横向空间去展示输入框两侧的错误信息提示，这就意味着放在右侧的错误信息提示对于手机端表单来说不是最好的位置。正确的处理方式是把错误信息提示放在输入框下方，这是用户第二偏好的位置。尽管这不符合用户的从左到右的自然阅读流程，但符合从上到下的阅读顺序。当用户阅读文本时，他们的视线是从左到右、从上到下地看。错误信息提示在输入框的下方是符合垂直的阅读顺序的。需要注意的是，把错误信息放在输入框下方时，不要与表单项目标题靠的太近，会容易形成干扰。

输入框的右侧 VS 输入框的下方：哪个是最佳位置？

输入框的右侧或下方都是错误信息提示的最佳位置。选哪个位置取决于你需要做多少工作。如果你想节省时间，桌面端和手机端设同一套的话，选下方位置。如果你有时间和资源为两端做不同的设计，那手机端选下方，桌面端选右侧，这个方案可帮助缩短用户在电脑端的视觉路径。

直觉的错误信息提示位置

总结一下， 错误信息提示的位置应该和用户的阅读流程保持一致，这样错误改正用到的成本最少。当减少用户操作和思考的时间精力，用户就能更快完成表格。没有人喜欢填写表单，因此，帮助用户更快地填写表单，产品的体验才能变得更好。原文：https://medium.com/@uxmovement/the-best-place-for-error-messages-on-forms-6e9e84740be8 作者：UX Movement 译者：胡白白 (公众号：彩云译设计 id:caiyunyisheji)

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论