我正在向向我们发送其他访问者的用户进行促销。这是在客户端完成的。
我可以使用动态 GET 参数来做到这一点，例如http://www.mysite.com?app_source=user_id 或者我可以使用哈希来做到这一点，例如http://www.mysite.com#app_source,user_id.
这些方法有什么优缺点吗？
【问题讨论】：
document.location 对象并 POST 到我们的服务器，就像 Google Analytics 一样
标签： javascript jquery http get tracking
对 GET 请求执行此操作的标准方法是简单地使用查询字符串。
http://www.mysite.com?app_source=user_id
如果您使用 URL 锚点，例如
http://www.mysite.com#app_source,user_id
锚点部分 (#app_source,user_id)未发送到服务器
例如，请参阅此related question。
这是另一个related question
锚只是一个客户端标志，告诉浏览器在页面上导航到哪里。
为了解决您的重定向问题，您可以在重定向之前处理查询字符串，添加/删除所需的键/值对，然后重定向。
PHP 让您可以使用$_SERVER['QUERY_STRING'] 直接访问查询字符串
Rails 使用 request.uri，您可以使用 parse
此外，当您看到像 facebook.com/#stuff 这样的奇特事物时，锚点部分由客户端 JavaScript 处理。所以你可以这样做，但你将编写发送正常 GET 请求的 ajax 代码，就像这个答案顶部推荐的那样。
为什么要增加复杂性？是不是更喜欢# 的外观而不是?？
【讨论】：
使用? 方法。为什么？因为这就是您应该跨页面传递任意数据的方式。
# 专门用于页面锚点。
除了语义和最佳实践之外，还有一个实际原因。想想当用户将访问者发送到页面上的锚点时会发生什么。您将无法使用散列方法（至少不能以简单的方式）。
所以我会遵循here 概述的方法：
function $_GET(q,s) {
s = s ? s : window.location.search;
var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}
var app_source = $_GET('app_source');
然后你可以有这样的 URL：http://www.mysite.com?app_source=user_id#anchor
【讨论】：
更语义的处理方式可能是通过查询字符串参数，但不是很强大。如果上述几点都不相关，我可能会坚持使用查询字符串，因为它更常见。
如果您的意思是您正在构建其他人集成的服务，并且您不希望他们必须将信息传递回他们的应用程序（通过查询字符串），那么使用哈希参数似乎是一个不错的选择。
【讨论】：
W3C 说here:
自然不能保证服务器不 由于执行 GET 请求而产生副作用；在 事实上，一些动态资源认为这是一个特性。重要的 这里的区别是用户没有请求副作用， 因此不能对他们负责。
【讨论】：
使用哈希。
为什么？
因为您开发了 3rd 方插件，并且不知道是否有任何参数不是站点开发人员的用户。当您覆盖使用的 get 参数之一时，您可以破坏本机应用程序开发人员传递给服务器的一些重要信息。 此外，您不想让应用程序持有人具有重复的页面，例如：http://somepage.com/ 和 http://somepage.com/?app_source=user_id 将是重复的，并且由于许多用户会引用该页面，您将创建其中的许多页面。
哈希是最安全的选项，可以在每个页面上使用。
【讨论】：
哈希是要走的路。
只有两种选择，一种是GET Parameter，第二种是#。
？获取参数
get参数可以被搜索引擎索引，两个网址http://www.yoursite.com/和http://www.yoursite.com/?app_id=123可以是2个单独的页面
在我的一个网站上，我使用了这个，我收到来自谷歌的电子邮件，说明
While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:
他们提到的链接可以正常工作，没有任何问题，但我仍然开始收到这些错误。
#哈希
哈希更好，因为它们不会改变任何 SEO 事物的行为（许多人会说它确实有影响，但我不这么认为）
最后，您只需要获取app_source 并使用Javascript 将其传递给您的服务器。所以你可以随心所欲。如果我是你，我会粗暴地使用 HASH
【讨论】：
你的方法都不好。 最终的方法是使用 URL Segments：
如果你想通过 App 和 UserId 来区分：
http://www.mysite.com/appName/UserID/
或仅按用户 ID：
http://www.mysite.com/UserID/
但我个人会同时使用 AppName 和 UserName：
http://www.mysite.com/appName/UserName/
【讨论】：
基于当今一些推广“#”符号的现代 Web 应用程序，对于支持 SPA（单页应用程序）如 Twitter 非常有用。请只使用“？”签名。
【讨论】：
简单的方法是使用带有 userID 的 GET 参数来验证它是否被某人引用。
http://www.mysite.com/?ref=1128721
然后，如果您想了解更多关于推荐的信息，您还可以使用$_SERVER['HTTP_REFERER']（如果您使用 php）检查用户实际点击您的链接的 URL。通过这种方式，您可以确保您的链接不在垃圾位置或“自动访问”中。
【讨论】：