很多人第一次听到“AI雷达名片”这个说法时，第一反应是：名片上怎么装雷达？其实这里的“雷达”指的是访客行为追踪与意向分析。做私域运营的公司、做企业级SaaS的工具商、想给销售团队配一套智能获客装备的运营者，大多数最后都会接触到这类产品——多用户独立管理智能AI雷达名片系统。它的核心价值在于：一套源码部署后，每个注册用户都能拥有完全独立的后台，配置自己的名片、管理自己的员工、查看访客轨迹，系统自动把浏览行为变成线索，按意向度打分排序。
这篇文章不讨论某个商业源码的购买点评，也不绑定任何具体产品品牌，而是从这类系统的通用技术形态出发，拆解它的架构思路、核心模块、数据库设计、部署流程和二次开发避坑点。标题里那句“带完整搭建部署教程”其实也透露出一个现实：市面上这类源码很多，但真正能把环境配置、伪静态、定时任务、公众号回调全部跑通的人并不多。下文就是给准备接手或自研这套系统的开发者一份能直接照做的实操笔记，做企业服务外包、SaaS创业、或者单纯想给团队搞一套获客工具的人都可以参考。
1. 项目定位与核心需求拆解
1.1 “多用户独立管理”到底在解决什么问题
先拆“多用户”这三个字。单机版名片工具只能自己用，一套系统绑定一个企业，这在今天几乎无法满足业务需求。多用户意味着平台化：系统部署在服务器上，开放注册入口，不同的公司、团队、个人都可以申请开通自己的空间。
“独立管理”是这个项目的核心卖点。每个用户在后台看到的、操作的都是自己那一亩三分地：自己的名片模板、自己的子账号、自己的访客记录、自己的客户线索。用户A永远看不到用户B的客户名单，管理员可以给用户开套餐、限名额、设权限。这种模式对应的是典型的SaaS租户隔离思路。
关键在于数据隔离和权限隔离。如果只是简单地在数据库表里加上user_id字段，不做好查询层的统一控制，多用户系统很容易出现水平越权漏洞，也就是普通用户通过改URL里的ID就能看到别人的数据。所以这类系统在架构设计阶段，就必须把“当前登录用户的ID”作为所有数据查询的默认过滤条件，而不是让前端传什么ID就查什么。
我见过不少开发者拿到源码后第一件事就是改后端逻辑，结果越改越乱。根本原因是没想清楚一个问题：多用户平台的“租户”维度是什么？有的系统以企业为单位开一个主账号，企业下面再挂多个员工子账号；有的系统直接个人即租户，每个销售自己一个独立空间。这两种模型在数据库设计上差别很大，前者需要企业表、成员表、角色表，后者只需要用户表和权限字段。标题里“独立管理”四个字，通常指的是每个用户都有独立的品牌空间、独立的域名绑定能力、独立的数据视图，这一点比单纯的多账号更重。
1.2 “智能AI雷达”的真实含义
再说“雷达”。在这类系统里，雷达不是硬件，不是图像识别AI，而是一套围绕访客行为的追踪与分析机制。名片页面里埋了统计代码，访客打开名片后，系统记录他的IP归属地、设备型号、浏览器类型、来源渠道、访问时间、停留时长、点击了哪些按钮、有没有提交表单、有没有复制电话。
这些行为数据进入后台后，被聚合成一个个“访客档案”。比如某个访客上午看了名片60秒，点开了地图导航，下午又通过朋友圈海报进来，停留了2分钟，还提交了询价表单，系统就会把他标记为高意向用户。这套过程在数据层面看起来不复杂，难的是采集端的稳定性、并发写入的承受能力、以及访客去重和评分算法的合理设计。
“雷达”这个词在营销上很性感，在技术上其实就是访客溯源。理解这一点很重要，因为在做二次开发的时候，大部分需求都会集中在这里：老板想看到客户看了多少次名片、每个销售手里有多少潜在客户、哪些渠道带来的访客质量最高。这套系统能把静态名片的“信息展示”变成获客入口，访客的每个动作都在产生线索。
1.3 典型应用场景与目标人群
这类系统最常出现的行业包括企业销售团队、房产中介、保险经纪、教育培训、展会获客、猎头顾问、汽车销售等。这些行业的共同特征是：业务高度依赖一对一沟通，谁先触达客户、谁能持续跟进，直接影响成交率。
还有个容易被忽略的场景是“异业合作和渠道代理”。很多公司买这套系统不是为了自用，而是为了部署后开账号卖给下游商家。比如某个城市服务商买一套源码，部署到自己服务器，然后以每年几百块的价格给本地商户开通独立空间，系统本身就成了可重复销售的数字产品。这也是“多用户独立管理”商业价值最高的地方。
目标人群概括起来有三类：一是做企业服务的软件公司或外包团队，二是做私域流量代运营的营销机构，三是有一定技术能力的企业数字化负责人。这三类人看这篇文章的诉求完全不同，但都需要先把部署和核心原理吃透。
2. 系统架构与核心模块设计
2.1 技术栈选型思路
这类系统在市面上最常见的技术组合是 PHP + MySQL + Redis，前端采用 H5 自适应页面加 Vue 单页应用，小程序端用 uniapp 或原生开发。PHP 系的优点是中小型项目开发效率高、部署方便、文档资料多，模板引擎和后台管理框架都很成熟，对“源码交付”这种模式非常友好。
具体选型上，后端框架多用 ThinkPHP 或 Laravel，前者在国内源码市场占有率很高，后者适合开发者自己从零搭建。数据库用 MySQL 5.7 或 8.0，Redis 负责缓存和队列。需要特别强调的是，访客行为上报接口一旦上线，并发量可能比名片展示接口高出一个数量级，如果每次都直接写 MySQL，高峰期很容易出现慢查询和锁表。正确做法是先写到 Redis 列表或队列，再由异步任务批量落库。
前端方面，名片展示页必须移动端优先，因为访客绝大多数是在微信里打开链接。管理后台用 Vue + Element 这类现成组件库可以大幅缩短开发周期，如果对颜值要求不高，服务端渲染的传统后台模板也完全够用。小程序端建议用 uniapp 同一套代码编译多端，避免维护两套原生代码。
| 层次 | 推荐技术 | 选择理由 |
|---|---|---|
| 后端 | PHP（ThinkPHP/Laravel） | 开发效率高、部署成本低、源码交付友好 |
| 数据库 | MySQL 5.7/8.0 | 生态成熟、数据一致性有保障 |
| 缓存与队列 | Redis | 处理访客行为上报的高并发写请求 |
| 后台前端 | Vue + Element UI | 组件丰富、适合管理端场景 |
| 名片页前端 | H5自适应页面 | 移动端访问体验优先 |
| 小程序端 | uniapp | 一套代码多端发布 |
2.2 数据库核心表设计
看这类源码时，第一件事是打开数据库，把核心表关系摸清楚。最关键的几张表是用户表、名片表、访客日志表、线索表、套餐订单表。用户表比较好理解，和常规系统差别不大，真正有门道的是后面几张。
名片表要保存的不只是姓名、职位、电话这些基础字段，还包括名片模板ID、背景图、语音介绍、企业微官网内容、公司地图坐标、分享标题和分享图等配置项。因为名片页是C端访客看到的第一个界面，它的展示完整性直接决定用户留存率。
访客日志表是整个雷达系统的核心资产，字段通常包括：租户ID、名片ID、访客唯一标识、IP地址、归属地、设备类型、操作系统、来源渠道、停留时长、点击路径、行为评分。其中访客唯一标识建议用哈希算法生成，比如把IP、UserAgent、当天日期拼接后做sha1，这样同一个访客在一天内的多次访问能归并到同一身份，又不至于把真实的用户个人信息明文入库。
线索表和访客日志表的区别在于：线索是已经“留资”的访客，也就是主动提交了表单、拨打了电话、或者通过电子名片交换留下联系方式的用户。线索表的核心字段是客户姓名、手机号、来源名片、所属销售、跟进状态、备注。从访客日志到线索的转化过程是否顺滑，决定了这套系统对销售团队的实际价值。
2.3 多用户独立管理的权限模型
多用户系统的权限模型一般分三层：平台超管、租户管理员、普通成员。超管负责审核开通账号、配置套餐、查看全平台数据；租户管理员可以管理自己空间内的成员、名片模板和线索；普通成员只能看到自己的名片的访客数据。如果涉及代理商模式，还会多一层代理角色，代理可以发展下级商户并从中获取分成。
实现上通常采用RBAC模型，角色表、权限表、用户角色关联表。套餐则单独用一张套餐配置表，字段包括套餐名称、价格、可开通的子账号数、可用模板数、雷达数据保留天数、是否支持自定义域名等。用户在购买或升级套餐后，系统自动调整他的功能权限，这里需要注意套餐到期后的降级逻辑，比如数据保留天数到了之后，历史访客记录要怎么处理，是隐藏还是删除，必须在代码里明确。
安全设计上有一条硬性要求：所有列表接口和详情接口，必须强制加上当前登录用户的租户ID。我排查过不少多用户源码的漏洞，最常见的低级错误就是后端接口只按前端传入的名片ID查询，完全不校验该名片是否属于当前用户，攻击者只需要遍历ID就能拖走全平台数据。正确写法是在每个数据查询里显式带上租户ID作为WHERE条件，而不是仅靠前端隐藏参数来做权限控制。
3. 搭建部署全流程实践
3.1 环境准备与基础要求
正式部署前先把服务器环境理清楚。这套系统建议使用 Linux 服务器，比如 CentOS 7 或 Ubuntu 20.04，配置方面测试环境2核4G起步，生产环境建议4核8G。Web服务器用 Nginx，PHP版本根据源码要求选择7.4或8.0，MySQL用5.7以上，Redis用6.x。
PHP扩展需要装全，常见缺口是 fileinfo、redis、curl、gd、pdo_mysql、opcache。很多系统安装后页面能打开，但一上传图片就报错，十有八九是gd扩展没装。还有个容易忽略的问题：PHP的post_max_size和upload_max_filesize默认值太小，名片模板要上传高清背景图、语音文件，默认2M限制根本不够用，部署时要同步调大，建议post_max_size设为50M，upload_max_filesize设为20M。
如果项目根目录有.env文件，先打开看看数据库连接等配置项是否齐全。源码包里的demo配置往往指向开发环境，不改直接上线会出现各种连接错误。按照我的部署习惯，我会先创建数据库、导入SQL、再改配置、最后配置站点，而不是先把站点指过去再回头处理数据库。
3.2 导入数据库与基础配置
用数据库管理工具创建空数据库，注意字符集选择utf8mb4，排序规则选择utf8mb4_general_ci或utf8mb4_unicode_ci。UTF8MB4是为了兼容表情符号和生僻字，移动端访客提交的表单内容可能包含表情，用utf8mb4才能正常存储。
然后导入源码包里的SQL文件。导入完成后建议核对一下表数量和数据表前缀。有些源码默认表前缀是tp_或xy_，后续在配置文件里填数据库信息时要保持前缀一致，否则程序找不到表。
导入SQL之后，接着改数据库配置文件。PHP框架一般有统一配置入口，比如.env文件或config/database.php，需要填写数据库地址、端口、用户名、密码、库名、表前缀。调试阶段建议打开DEBUG模式，方便查看具体报错；上线前务必关闭DEBUG，避免暴露敏感信息。
3.3 Nginx伪静态与运行目录配置
部署这类源码最容易踩的坑就是站点根目录配置错误。出于安全考虑，项目的运行目录通常是public目录，而不是项目根目录。把站点根目录指向public后，访问者无法直接读取到项目目录里的配置文件、日志文件、源码备份，这是一个基本的安全边界。
我给一个Nginx配置示例：
server { listen 80; server_name card.example.com; root /var/www/card/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ { expires 30d; access_log off; } }配置完成后用nginx -t检查语法，重载服务。打开主页如果出现404，多半是伪静态规则没生效，检查一下location /里的rewrite规则是否被注释。如果出现403，检查public目录下的index.php是否有读取权限，以及目录是否存在于正确路径。
3.4 定时任务与队列配置
如果系统里集成了访客日志异步落库、每日数据汇总、字段回收等功能，就一定需要配置crontab定时任务。很多源码运行几天后雷达数据不更新、线索不变化，不是程序坏了，而是定时任务压根没配。
典型的crontab配置长这样：
* * * * * php /var/www/card/think crontab >/dev/null 2>&1路径要根据实际项目位置调整，think是ThinkPHP的命令行入口。如果不确定PHP在命令行下的路径，先用which php查一下，常见的路径是/usr/bin/php或/usr/local/bin/php。如果配置了Redis队列消费者，还需要单独启一个常驻进程。不要过度依赖crontab做实时性要求高的队列消费，建议用systemd管理进程服务。
部署后如何验证定时任务生效？最简单的方法是在源码里找一个写日志的任务，手动执行一次命令，再查看是否生成日志或更新数据库。或者临时在crontab命令后面加上输出重定向到一个可读的日志文件，然后观察内容变化。
3.5 公众号与小程序对接参数
名片系统通常需要和公众号、小程序对接，才能实现微信内打开名片、获取访客OpenID、静默授权等能力。公众号后台需要配置服务器地址、Token、EncodingAESKey，并把服务器IP加入白名单，同时配置网页授权域名和JS接口安全域名。
回调地址一般形如https://你的域名/index.php/api/wechat/notify，填写时注意必须使用HTTPS协议，公众号后台对安全要求比较严格。如果你的服务器没有配置好SSL证书，这步就会卡住。
小程序端的对接还要在开发设置里配置服务器域名，把request合法域名指向你的API域名，把业务域名指向名片H5页面域名。否则小程序里打开链接和请求接口都会被拦截。另外，目前微信生态对于涉及用户收集的隐私接口有审核要求，提交小程序版本前要仔细阅读平台规则。
3.6 HTTPS证书与安全加固
前面提到公众号回调需要HTTPS，所以域名证书是逃不掉的。用云服务商提供的免费证书即可，下载Nginx格式证书，配置到server块中：
listen 443 ssl; server_name card.example.com; ssl_certificate /etc/nginx/ssl/card.pem; ssl_certificate_key /etc/nginx/ssl/card.key; ssl_protocols TLSv1.2 TLSv1.3; if ($scheme = http) { return 301 https://$host$request_uri; }配置完成后用https访问测试。这里有个很容易被忽略的问题：HTTPS环境下如果框架里cookie设置了secure属性，HTTP访问时cookie就写不进去，用户登录状态可能会异常。判断标准很简单——上线后频繁出现“登录后跳转又回到未登录”的情况，先查cookie配置。
4. AI雷达的核心实现与意向度模型
4.1 访客行为数据是怎么采集的
名片页想要统计到访客行为，前提是在页面中引入统计脚本。头部加载时上报一次页面浏览事件，点击电话、导航、表单提交时再上报对应事件。上报参数至少包括：名片ID、事件类型、来源渠道、当前页面URL、访客设备信息。
简化的前端埋点示例：
window.addEventListener('load', function () { var payload = { card_id: document.querySelector('#cardId').value, event: 'view', referrer: document.referrer, ua: navigator.userAgent, stay: 0 }; fetch('/api/radar/report', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) }); });看到这里你应该明白，所谓“AI雷达”在采集端就是一次普通的HTTP请求。真正拉开差距的是服务端如何处理这些请求：先去重、再归因、再打分。每个访客首次访问时生成一个访客标识，后续再回来时根据标识关联历史行为，形成连续追踪。
还有一点值得提醒：有些设备上的浏览器会拦截跨域请求或第三方Cookie，导致访客识别不准。常见的缓解手段是把访客标识存放在本地存储中，上报时带上，服务器优先信任这个标识。当然，如果访客清除了浏览器数据，身份识别就会从头开始，这是纯前端方案的物理限制。
4.2 意向度评分模型的通用算法
访客访问数据有了，但原始数据不会自动告诉你谁是高质量客户。意向度评分的作用就是把行为转化为可量化的分数，让销售按分数排序跟进。
一个可落地的评分思路是基础分加行为分，再乘时间衰减系数。参考公式如下：
$score = 0; // 基础活跃分：访问次数越多，基础分越高，但封顶避免刷量 $score += 5; // 首次访问 $score += min($visit_count - 1, 10); // 额外访问每次加1，最多加10 // 时长分：停留超过阈值加分 if ($stay_seconds >= 30) $score += 3; if ($stay_seconds >= 60) $score += 5; if ($stay_seconds >= 120) $score += 8; // 关键行为分：点击电话、地图、官网、表单 if ($clicked_phone) $score += 10; if ($clicked_map) $score += 6; if ($clicked_site) $score += 6; if ($submitted_form) $score += 30; if ($shared_link) $score += 15; // 时间衰减：超过7天，每多1天，意向度衰减 $decay = exp(-$days_since_last_visit / 7); $score = round($score * $decay);为什么表单提交分值给到30那么高？因为访客留下手机号的行为意味着他主动建立连接的需求，这种动作的转化概率远高于单纯浏览。点击电话次之，能点开地图找店的也有一定意向。浏览时长则是一种辅助信号，单独不能说明太多，但和留资行为叠加后能识别出“反复研究名片但犹豫不决”的潜在客户。
这种模型的价值在于可配置。给不同行业部署时，销售团队对“意向”的定义完全不同，做B2B大客户培训和做快消品零售的判断标准没法统一。所以成熟的系统在后台都会提供权重设置，让运营者调整各项行为的得分。
4.3 线索管理与自动标签
雷达识别出高意向访客之后，系统要把这个人从“访客”升级为“线索”。常见的线索入库来源有四种：访客主动提交表单、通过电子名片交换、销售手动录入、系统根据雷达评分自动生成建议线索。线索表里至少要有姓名、手机号、来源名片、所属销售、得分、标签、跟进状态。
标签是线索管理里比较实用的功能。系统可以基于访客行为自动打标签，比如“高频访问”“高意向”“表单留资”“仅浏览”。销售在后台也可以手动补充标签，比如“价格敏感”“竞品对比中”“已预约拜访”。自动标签和手动标签分开存，查询时合并使用。
线索跟进状态的字段设计不要过度复杂。常规的状态流转是新线索、跟进中、已成交、无效。每个销售在跟进时可以更新备注，备注内容最好做成带时间戳的跟进记录表，而不是只留一个更新字段。这样管理者可以清晰看到每个销售对同一个客户的跟进节奏，后续做团队管理报表时也方便统计。
5. 常见问题与排查技巧实录
5.1 部署期最容易踩的5个坑
第一个坑是运行目录错误。项目根目录和public目录傻傻分不清，直接把网站在线指向了根目录，静态资源找不到、入口文件被隐藏目录跳过，报错五花八门。解决办法很简单：统一把站点root指向public。
第二个坑是伪静态404。打开首页能跑，但一到带参数的页面就404，基本是Nginx的rewrite规则缺失。对照前面给的location配置核查一遍。
第三个坑是storage目录没有写权限。日志、缓存、上传图片都需要写目录，很多源码安装时跳过目录权限设置，运行一段时间后突然报错，看着像硬件故障，其实是磁盘写满了或权限不对。
第四个坑是数据库连接失败。如果报错了，先排查数据库账密、端口、表前缀，其次是Redis的密码是否配置。注意有些服务器Redis默认没有密码，源码里配置了密码反而连不上。
第五个坑是定时任务没跑。雷达数据有，但首页统计不变，或访客日志不落库，多半是crontab进程没有生效。先在服务器手动执行命令，确认能跑，再看cron服务是否启动。
5.2 雷达不记录访客，从头排查的完整路径
雷达功能失灵是这类系统最让人头疼的问题。我的排查顺序是固定的：先确认前端是否发出了上报请求，再用接口日志确认服务端是否收到，最后看队列和数据库。
打开名片页，按F12进入开发者工具，切到Network面板，筛选“radar”“report”之类的请求名。如果根本没有请求，说明前端脚本报错或压根没加载，检查浏览器控制台是否有JS错误，顺便看看页面head里有没有引入统计脚本。如果请求发出去了但返回404，多半是后端路由没有配置或伪静态规则有问题。
如果接口返回200但数据库里没有新增记录，问题通常出在队列消费环节。命令行手动执行队列消费脚本，观察是否有报错。另一种常见情况是Redis连接超时，比如Redis服务没启动、内存满了、密码不匹配。
数据库有记录但后台统计页面不变化的话，就需要看聚合任务。很多雷达系统为了性能，每天凌晨用定时任务生成统计快照，不会实时更新所有数字。
5.3 多用户系统的数据隔离与越权漏洞排查
做二次开发时最需要警惕的就是数据越权。最简单的验证方法：用A用户账号创建一张名片，记录名片ID，然后退出登录，用B用户账号直接访问“名片详情”接口，把名片ID改成A的，看看能否查到A的名片数据。
如果查到了，说明后端没有做租户隔离。修复的方向是在业务逻辑层强制绑定当前登录用户ID，例如以下简化代码：
$card = Card::where('id', $input['card_id']) ->where('tenant_id', session('tenant_id')) ->first(); if (!$card) { return error('名片不存在或无权访问'); }这个思路要贯穿到所有涉及数据的接口，包括名片列表、访客记录、线索列表、订单记录。做全局统一处理更稳妥，比如在一个公共的查询作用域里强制注入租户条件，这样即使新开发的模块不小心漏了判断，也会被兜底拦截。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查与解决方法 |
|---|---|---|
| 访问域名打不开 | 站点配置未生效、80端口未放行 | 检查Nginx配置、云服务器安全组策略 |
| 首页正常但详情页404 | 伪静态规则未生效 | 检查Nginx rewrite规则并重载配置 |
| 数据库连接失败 | 账密错、端口错、表前缀不一致 | 核对配置文件与数据库实际情况 |
| 图片上传报错 | gd扩展缺失、目录无写权限 | 安装扩展、调整storage目录权限 |
| 登录状态丢失 | Cookie secure配置、HTTPS切换 | 检查session配置与Cookie参数 |
| 雷达无数据 | 前端脚本未加载、队列未消费 | 按前端请求、后端日志、数据库顺序排查 |
| 访客在后台看不到 | 聚合定时任务未运行 | 手动执行定时任务并检查日志 |
| 用户访问他人名片 | 租户隔离缺失 | 后端强制绑定当前用户租户ID |
| 微信内名片空白 | 域名未备案或HTTPS证书异常 | 检查证书链、备案状态、调试页面 |
6. 二次开发与商业化落地建议
6.1 从源码到产品的常用扩展点
一套基础的名片雷达系统做完后，最常被要求的扩展需求包括：和企业微信打通、对接已有CRM系统、增加可视化名片模板编辑器、与短信服务商集成、支持电子签章。这些功能在技术上都属于常规模块，但开发时要注意与现有权限模型保持一致，不要做成几个信息孤岛。
打通企业微信的价值最明显。访客留资后，系统可以实时推送给对应销售的企业微信，并尝试直接添加客户为好友。消息通知用的是企业微信应用消息接口，需要在企业微信后台创建自建应用，拿到CorpID和Secret，再在源码的后台配置项里填入。推送逻辑用队列异步处理，避免接口超时影响访客的使用体验。
和第三方CRM对接时，优先采用Webhook方式而不是直接读写对方数据库。线索产生、跟进状态变更、成交时，向CRM推送一条JSON消息。这样两个系统解耦，对方升级接口、我们改字段，都不会互相影响。
6.2 多用户SaaS运营的盈利模式
部署完源码只是开始，真正赚钱的是运营环节。市面上几种跑通的模式可以借鉴。第一种是源码加部署服务费，一次性收费，帮客户在指定服务器装好，附赠培训，适合做本地化服务的外包团队。第二种是SaaS年费模式，平台自己持有系统，给每个商户开通独立空间，按年收费，包含技术支持和数据备份。第三种是代理分销模式，给代理商开下级权限，代理商自己发展商户，平台从代理的充值中抽成。
无论是哪种模式，都建议在后台做好套餐管理。免费版限制子账号数和雷达数据保留天数，付费版解锁高级模板和AI评分功能，这样既保证了基础体验，又能推动用户升级。我这里特别提醒一点：收费标准要按“API调用量或数据存储量”设置阶梯，而不是只按人头数，不然高活跃商户很容易把服务器资源耗光。
6.3 数据安全与合规提醒
部署这类系统涉及用户信息和访问行为数据，安全底线要守住。首先是数据传输加密，全站启用HTTPS，敏感接口加签名或鉴权。其次是数据备份，数据库和上传文件每天都做增量备份，至少保留7天。
雷达上报接口属于高并发场景，容易成为攻击目标。必须做频率限制，比如按IP和名片ID限流，单个IP每分钟上报次数超过阈值就丢弃或返回错误码。否则有人写个脚本循环刷接口，访客日志表一天就能膨胀几个G，数据库直接被拖垮。
内容安全方面，多用户系统会产生大量UGC内容，比如名片简介、企业介绍、动态海报。这些内容需要前端输入过滤加后端内容审核，至少要有敏感词过滤机制。另外，涉及用户隐私的数据导出操作，后台要保留审计日志，避免内部人员违规导出客户数据。
最后再说两句
多说一点实际感受。做这类系统的部署和二次开发，真正决定成败的往往不是高深的技术，而是那些看起来不起眼的细节：运行目录是否指对、定时任务有没有配、伪静态规则是不是少了一行、cookie的secure参数在HTTPS下有没有出问题。把基础环节做到位，系统就能稳定跑起来；基础环节出问题，再好的AI雷达模型也只是摆设。
意向度模型看起来只是几个加法，但真正要调好并不容易。不同行业的客户行为差异很大，与其照搬一套标准参数，不如先在后台跑两周数据，观察高分访客的成交率，再回头调整各项权重。
如果你正准备自己部署一套这样的系统，我的建议是先在测试服务器完整走一遍这篇流程，把每一处配置都亲手操作一次。跑通之后再考虑定制功能、接入企业微信、做套餐运营。想要靠这个系统赚钱，稳定性永远是第一位，一个半夜宕机没人处理的雷达系统，会很快消耗掉运营方的信任。
